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EXECUTIVE  SUMMARY 

This  report  documents  the  results  of  software  enhancement  and  version  release  test 
work  for  the  DSCS  Network  Performance  System  (ONPS).  The  effort  was  addressed 
through  three  subtasks: 

*  Subtask  A — Requirements  Analysis,  Development,  and  Test 

*  Subtask  B--Version  Release  Test  Support 

*  Subtask  C— -Integration  of  the  Receive  Multiple  . Beam  Antenna  (MBR)  Resource 
Allocator. 

The  subtasks  were  conducted  through  the  period  December  1984  -  November  1985. 
Subtask  A  -  Requirements  Analysis,  Development,  and  Test 

The  purpose  of  Subtask  A  was  to  evaluate  the  utilization  of  the  DSCS  Operational 
Control  System  (DOCS).  Although  the  results  of  this  work  are  detailed  in  a  task  Interim 
Report  published  on  9  Sept  1985  (repeated  here  in  Section  B.1  through  B.4  of  Appendix  B 
for  convenience),  two  new  recommendations  for  enhancements  to  the  DNPS  are 
contained  in  Chapter  1  of  this  report. 


Subtask  B  -  Version  Release  Test  Sut 


The  purpose  of  Subtask  B  was  to  maintain  software  integrity  of  the  DOCS.  Efforts 
included  testing  of  the  DNPS  version  3.1  electronic  counter-countermeasure  (ECCM) 
subsystem  and  verification  of  the  DSCS  Operational  Support  System  (DOSS)  2.1  and  DNPS 
3.1  Allocation  and  Performance  subsystems.  An  overview  of  this  testing  effort  is  provided 
in  Chapter  2.  Appendix  A  contains  the  Test  Plan/Report. 


Subtask  C  -  Integration  of  the  Receive  Multiple  Beam  Antenna  (MBR)  Resource  Allocator 


Under  Subtask  C.  a  previously  developed  multiple  beam  antenna  (MBA)  resource 
allocator  algorithm  (software  name,  MBR_AAS)  was  integrated  into  the  DNPS  under  the 
analysis  support  function.  Results  obtained  with  the  MBR_AAS  software  exhibited  slow 
convergence  to  the  desired  MBA  gain  pattern  and,  in  many  cases,  an  inability  to  converge 


1 


to  an  acceptable  gain  pattern.  Efforts  therefore  focused  on  the  development  of  a  new 
MBR  steering  algorithm  with  improved  convergence  properties.  Initial  results  of  the  new 
algorithm,  the  Cholesky  reduction  algorithm  (lower/upper  triangular  matrix  decompostion), 
are  in  excellent  agreement  with  the  user-supplied  MBR  (desired)  directive  gain  contours. 
An  evaluation  of  the  Cholesky  reduction  algorithm  and  results  of  its  application  in  this 
work  are  provided  in  Chapter  3.  This  report  provides  a  detailed  examination  of  the 
MBR  AAS  algorithm  in  Sections  B.S  through  B.7  of  Appendix  B,  with  test  results  in 
Appendix  C. 


Chapter  1 

REQUIREMENTS  ANALYSIS,  DEVELOPMENT,  AND  TEST 


1.1  SUBTASK  A 

The  purpose  of  this  subtask  was  to  develop  and  implement  modifications  of  the  uCEC 
version  of  the  OSCS  Operational  Control  System  (DOCS)  Network  Planning  Software 
(DNPS)  in  response  to  needs  identified  by  OCEC. 

In  concert  with  the  DCEC  task  officer,  it  was  agreed  that  the  majority  of  the  effort 
expended  under  this  subtask  was  to  be  an  examination  of  the  current  DOCS/DNPS 
structure  and  general  techniques  that  could  be  used  for  growth  and  expansion  of 
capabilities.  Most  efforts  on  this  subtask  were  completed  in  September  85  and  presented 
in  an  interim  report.  For  ease  of  reference,  the  earlier  reported  results  of  Subtask  A  are 
given  herein  in  Appendix  B. 


The  top-level  functional  organization  of  DNPS  is  given  in  Figure  1-1.  The  functions  of 
DNPS  use  a  complex  series  of  operator  inputs  and  runt.  -ie  definitions  to  compute  the 
resultant  evaluation  of  DSCS  network  performance.  The  following  additional 
recommendations  would  assist  the  operator  and  enhance  the  software: 


•  DNPS  Interactive  Help  Function  - 

Using  the  'Utilities'  section  of  the  program  as  the  entry  point,  the  help 
function  would  echo  the  top-level  DNPS  menu.  Help  is  displayed  on  the 
terminal  when  the  operator  selects  a  subsystem  (for  example  '2/  which  is 
currently  the  procedures  subsystem).  The  program  could  then  offer 
assistance  on  the  operator's  terminal  ranging  from  a  terse  overview  to  a  very 
detailed  description  of  the  subsystem.  The  data  displayed  would  be 
determined  by  the  operator  or  the  "lever  at  which  this  enhancement  is 
implemented.  The  "level"  of  enhancement  is  the  level  at  which  the  DNPS 
program  is  documented  (via  the  enhancement).  For  example,  the  Scenario 
Definition  subsystem  offers  many  sublevels  of  program  usage,  thus  the  level 
of  enhancement  is  the  point/subievel  that  the  documentation  stops.  The 
following  improvements  could  be  realized: 


o  Improved  operator  performance  - 

The  user  could  have  program  documentation  displayed  when  needed. 
The  display  could  be  copied  to  the  printer  if  desired. 


Figure  1-1.  Functional  Organization  of  ONPS 
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Up-to-date  manual  - 

As  the  program  changes,  the  documentation  should  be  concurrently 
updated/refined. 

o  Program  limitations  - 

Any  known  problems  and/or  limitations  of  the  current  version  should  be 
listed.  This  would  avoid  the  issuance  of  redundant  Software  User 
Reports  (SURs). 

*  Improved  User  Procedures  - 

The  ability  to  'pass'  an  argument  to  a  procedure  as  it  is  invoked  would 
enhance  the  program.  This  argument  would  be  a  datum  required  in  the  body 
of  the  procedure  and  be  substituted  at  the  point  it  is  used.  The  definition  of 
the  argument  (identification  of  the  argument  to  the  program)  is  determined  at 
the  time  the  procedure  is  created.  An  alternate/additional  method  is  to 
terminate  input  from  the  procedure  file  and  obtain  input  from  the  operator. 
The  procedure  would  then  continue  reading  data  from  the  procedure  file. 

Data  modification  provides  an  example  of  how  this  enhancement  could  be 
used.  In  a  sample  invocation,  the  data  rate  is  the  user-defined  argument.  The 
body  of  the  procedure  would  step  through  the  program  subsystems  to  change 
the  data  rate  of  various  links;  then,  reports  would  be  generated.  The 
procedure  would  be  invoked  again  and  a  different  data  rate  supplied  and 
reports  generated.  The  time  required  to  perform  ->e  change  and  produce 
reports  would  be  significantly  reduced.  The  creation  of  one  procedure  would 
speed  the  ability  of  an  operator  to  evaluate  the  effects  of  many  different  data 
rates. 


Chapter  2 

VERSION  RELEASE  TEST  SUPPORT 


2.1  SUBTASK  B 

As  modifications  were  made  or  were  planned  to  be  made  to  the  operationally  fielded 
system,  these  changes  were  incorporated  into  the  OCEC  system,  and  the  resultant 
software  was  tested  for  performance  integrity.  During  this  modification  and  test  process, 
an  exact  duplicate  of  the  operational  software  was  maintained  for  use  by  DCEC  engineers. 

2.1.1  Test  Support  Overview 

Testing  and  analysis  was  performed  under  this  subtask  on  the  3.1  version  of  DNPS.  In 
addition,  regression  testing  was  performed  on  version  2.1  of  DNPS  using  a  typical 
predefined  scenario.  This  regression  testing  was  performed  to  ensure  that  any  major 
changes  which  were  made  to  the  computational  algorithms  provided  validated  output 
predictions. 

The  preliminary  Version  Test  Plan/Report  is  given  in  Ap^ndix  A.  The  analysis  phase  of 
the  testing  effort  is  still  in  progress.  The  final  version  of  the  Test  Plan  and  Report  is 
scheduled  for  release  in  1986. 


2.1.2  Test  Support  Recommendations 

Because  of  the  numerous  submenus  of  DNPS  and  menus  that  are  only  displayed  when 
certain  conditions  arise,  the  following  recommendations  are  made: 

*  Test  procedures  should  be  provided  through  a  single  source. 

*  Concise  and  approved  test  procedures  should  be  provided  with  any  release  of 
the  software. 

*  The  test  procedures  should  be  addressed  at  the  time  any  software 
modifications  are  introduced  at  the  Configuration  Control  Board  review.  The 
level  of  testing  required  for  acceptance  should  be  resolved  when  the  change 
is  accepted. 

*  The  DNPS  package  should  be  tested  using  automated  methods.  This  would 
ensure  that  any  previously  working  code  remains  unaffected  and  any  new 
code  will  be  tested.  Automated  testing  would  create  known  output  and 


program  response  (based  on  automated  input).  Deviations  in  program 
response  and  output  (in  a  new  version  of  software)  would  indicate  a  change 
in  the  software  package. 


Chapter  3 

INTEGRATION  OF  THE  RECEIVE  MULTIPLE  BEAM  ANTENNA  RESOURCE  ALLOCATOR 

3.1  SUBTASK  C 

DCEC  personnel  have  begun  work  on  an  algorithm  to  optimize  the  allocation  of  the 
DSCS  ill  receive  multiple  beam  antenna  and  to  allow  for  the  definition  of  'areas*  of 
antenna  coverage  and  directive  gain.  This  algorithm  currently  resides  on  the  VAX-11/780 
computer  at  the  OCEC  Hybrid  Simulation  Facility.  Under  this  subtask,  work  on  the 
development  of  the  optimization  algorithm  continued  (to  include  a  demonstration  test 
conducted  for  the  government)  to  the  point  where  the  algorithm  could  be  integrated  into 
the  ONPS. 

Analysis  of  the  MBRAAS  algorithm  was  provided  in  an  interim  task  report  and  is 
given  in  Appendix  B  (Sections  B.5  through  B.7)  and  in  Appendix  C  for  ease  of  reference. 

3.2  SUMMARY  OF  NEW  BEAM  FORMING  ALGORITHM  STUDIES 

The  MBR  antenna  is  composed  of  61  individual  sing.et  beams  whose  outputs  are 
electronically  (using  in-phase  and  quadrature  weights  at  RF)  weighted  and  summed  to 
produce  a  desired  composite  gain  distribution  on  the  earth's  surface. 

Two  numerical  analysis  techniques  have  been  investigated  to  determine  the  required 
beam  weighting  to  approximate,  in  a  minimum  mean  square  error  (MSE)  sense,  desired 
gain  contours  on  the  surface  of  the  earth.  One  method  is  a  functional  minimization  of 
the  MSE  between  the  actual  and  desired  gain  values  using  a  gradient  technique  to  search 
for  the  optimum  weighting  vector.  A  second  method  is  the  numerical  solution  of  a 
system  of  simultaneous  linear  equations  to  find  the  beamweight  vectors  that  minimize  the 
MSE  between  the  desired  and  actual  gain  contours.  The  latter  approach  was  pursued 
first.  An  IMSL  (International  Mathematical  and  Statistical  Library)  library  routine  was 
selected  to  perform  the  numerical  solution.  The  technique  used  by  IMSL  is  the  lower 
triangular-upper  triangular  (LU)  decomposition  (also  named  Cholesky  reduction),  a 
modification  of  the  Gauss-Jordan  elimination  method  more  suitable  for  computer 
processing. 


To  test  the  algorithm,  a  singlet  data  matrix  was  generated  using  ideal  singlet  beam 
patterns  based  on  an  assumption  of  a  uniformly  illuminated  circular  aperture  antenna. 
This  matrix  consists  of  61  column  vectors  (corresponding  to  each  of  the  61  singlet 
beams)  with  the  elements  of  each  column  vector  corresponding  to  ideal  element  gain 
values  at  each  point  in  the  field  of  view.  This  matrix  specifies  the  singlet  beam  patterns 
with  0.2°  granularity  over  the  full  earth  field  of  view  of  ±9°  azimuth/elevation  from  the 
boresight  of  the  center  beam  of  the  MBR.  This  results  in  8281  points  of  interest  (gain 
values)  on  the  earth  surface  for  each  of  the  61  singlet  beams.  The  singlet  data  matrix  is 
therefore  of  size  8281  x  61.  As  part  of  the  initial  test,  a  desired  gain  vector  (8281  x  1) 
(i.e.,  full  earth  field  of  view)  was  selected  with  elements  equal  to  one  column  of  the 
singlet  data  matrix.  That  is,  the  desired  gain  contour  was  set  equal  to  the  gain  contour 
of  one  singlet  beam  of  the  61-beam  MBR.  The  resultant  weighting  vector  generated  by 
the  algorithm  consisted  of  60  zero  weight  elements  and  unity  weighting  for  the  beam 
whose  singlet  gain  contour  was  equal  to  the  desired  gain  contour.  That  is,  to  achieve  the 
desired  gain  contour,  the  weights  of  all  beams  in  the  MBR  were  set  to  zero  by  the 
algorithm  except  the  one  whose  gain  matched  that  of  the  desired  gain.  This  result 
provided  a  good  initial  test  of  the  accuracy  of  the  algorithm. 

Further  testing  was  performed  using  an  actual  contour  pattern  developed  for 
continuous  wave  (CW)  acceptance  tests  of  the  DSCS  III  A1.  Data  points  for 
azimuth/elevation  angle  and  gain  level  were  obtained  for  the  contours  given  by 
"sampling"  every  0.2°  of  azimuth.  A  singlet  data  matrix  was  generated  for  these  points 
using  the  ideal  singlet  beam  approximation  described  above.  The  desired  gain  vector  was 
obtained  directly  from  the  sampled  contour  data  A  weighting  vector  was  then  computed 
and  the  resultant  gain  vector  was  determined.  A  contour  plotting  program  was  written 
and  the  contours  (levels)  of  interest  were  drawn  based  on  the  resultant  gain  values. 
Simple  desired  contour  patterns  were  approximated  very  closely.  The  more  complex  the 
desired  contour,  the  more  difficult  it  was  to  compute  the  appropriate  beam  weights  to 
synthesize  the  desired  pattern.  This  was  a  result  of  the  use  of  ideal  singlet  data  and  the 
fact  that  the  desired  gain  contours  were  obtained  using  actual  (non-ideal)  MBR  singlet 
data.  Once  the  actual  MBR  singlet  data  became  available,  a  new  beamweight  vector  was 
computed  and  the  resultant  gain  vector  was  determined.  The  resultant  contour  plots 
using  actual  measured  singlet  beam  patterns  showed  a  much  closer  match  to  the  desired 
contours  than  had  previously  been  obtained  using  ideal  singlet  data. 


t 


y 


Another  test  performed  involved  jammer  nulling.  The  actual  contour  pattern  described 
above  was  modified  to  include  a  jammer  null  at  an  arbitrary  location.  The  beamweight 
vector  was  computed  as  before  (using  actual  singlet  data)  for  several  different  nulling 
depths  at  the  jammer  location  of  interest.  The  resultant  gain  distributions  were 
determined  and  contours  were  plotted.  Although  excellent  matches  between  desired  and 
actual  patterns  were  achieved,  it  was  found  that  the  greater  the  depth  of  the  desired  null 
relative  to  the  close  surrounding  contours,  the  more  difficult  it  was  to  match  the  desired 
contour  patterns.  This  is  due,  in  part,  to  the  limited  resolution  of  the  61  element  earth 
coverage  MBA  and  to  the  fact  that  only  the  "natural*  •  phase  of  the  MBA  was  used  for  the 
desired  gain  contour  points  instead  of  a  phase  requirement  designed  to  emphasize  the 
desired  null. 


The  second  algorithm  (functional  minimization)  was  developed  in  software  and  used  to 
improve  upon  the  results  obtained  using  the  first  algorithm  (LU  decomposition).  The 
functional  minimization  approach  requires  an  initial  guess  for  the  beamweight  vector 
which  is  modified  to  minimize  the  MSE  between  the  actual  and  desired  gain  values.  The 
initial  beamweight  vector  used  as  input  to  the  algorithm  is  obtained  from  the  LU 
decomposition  algorithm  solution.  A  significant  improver  ent  in  matching  the  resultant 
gain  contours  to  the  desired  has  been  observed  and  is  documented  in  section  3.6.1. 

The  model  description,  numerical  methods  and  test  results  are  described  below. 


3.3  MODEL  DESCRIPTION 

The  MBR  antenna  is  composed  of  61  individual  singlet  beams.  The  maximum  gain  that 
each  singlet  beam  can  produce  at  a  given  azimuth/elevation  (on  the  earth's  surface 
relative  to  the  satellite)  Is  given  by  the  singlet  data.  A  singlet  data  matrix  can  be 
constructed  for  specific  areas  of  interest  on  the  earth  surface.  This  matrix  has  the  form: 


A  *  (a  ♦  j  s  1 

1  m.n  1  Mm,rt  Jm.n 


where  m  *  azimuth/elevation  coordinate  index;  m  *  1,2 . M 

n  «  singlet  beam  index;  n  »  1,2 . N 

That  is.  each  of  the  M  rows  of  A  corresponds  to  a  specific  azimuth/elevation 
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coordinate  point  within  the  area  of  interest  and  each  of  the  N  columns  corresponds  to  a 
particular  singlet  beam.  The  maximum  coordinate  index  M  may  vary  from  one  point  to 
full  coverage  of  8281  points'.  The  number  of  columns  of  A  will  generally  equal  61.  since 
all  61  beams  normally  would  be  considered.  Each  A  matrix  element  is  a  complex  number 
representing  the  real  and  imaginary  components  of  the  maximum  gain  of  a  given  singlet 
beam  at  an  azimuth/elevation  point.  The  MBR  singlet  beams  are  electronically  weighted 
and  summed  to  produce  a  desired  composite  gain  distribution  on  the  earth  surface. 
Algebraically,  this  is  equivalent  to  multiplying  the  singlet  data  matrix  A  times  a 
beamweight  column  vector  W  consisting  of  61  complex  elements,  each  element 
corresponding  to  the  weighting  applied  to  an  associated  singlet  beam.  The  result  is  a 
gain  vector  G  whose  elements  represent,  in  general,  the  complex  gain  at  each 
azimuth/elevation  point  within  the  areas  of  interest  defined  by  the  A  matrix.  Symbolically, 

G  -  AW  3.2 

where  A  -  [<*m  „  ♦  i  8m  n  lm  n 
^  *  lTn  ♦  i  «„ 

G  -  [Am  *  j  ]m, 

3.4  NUMERICAL  ANALYSIS  TECHNIQUES 

3.4.1  Algorithm  1:  Minimum  Mean  Square  Error  Solution  for  Complex  Gain  Contours 

The  MBR  antenna  beam  forming  problem  is  to  compute  the  beam  weights  for  the  61- 
element  antenna  to  synthesize  a  given  desired  gain  contour.  Two  approaches  were 
considered.  The  first  approach  is  to  specify  the  desired  gain  contour  in  terms  of 
magnitude  and  phase  (complex)  and  to  minimize  the  weighted  MSE  given  by 

e2  MG,  -  Gd}*  B  (Ga  -  Gd)  3.3 

where  Gd  »  desired  gain  vector  (M  x  1) 

G#  *  actual  gain  vector  (M  x  1) 

B  -  diagonal  weighting  matrix  related  to  the  relative  importance  of  areas 
of  interest  (for  unbiased  weighting  of  all  points  within  the  coverage 
area,  B  is  an  identity  matrix) 


Pull  earth  coverage  consist*  of  *  9°  azimuth  and  alavation,  with  0.2°  granularity,  from  tha  subsatallita  point 
of  a  geosynchronous  satellite. 


(*)  *  complex  conjugate  transpose  of  a  given  matrix  or  vector 

Since  the  actual  gain  vector  G,  may  be  written  as 

G#  -  AW  3.4 

where  A  -  singlet  data  matrix  (M  x  61) 

W  -  beamweight  vector  (61  x  1) 

the  weighted  mean-square-error  function  e2  becomes 

E2  -  (AW  -  Gd)*  B  (AW  -  Gd)  3.S 

Setting  the  gradient  of  e2  equal  to  zero  yields  a  system  of  61  equations  in  61 
unknowns  given  by 

A*BAW  -  A*8Gd  3.6 

Many  standard  numeric  analysis  methods  can  be  used  to  solve  this  system  for  the 
beam  weight  vector  W.  An  IMSL  FORTRAN  library  routine  was  selected  to  perform  the 
numerical  solution.  The  technique  used  by  IMSL  is  an  ID  decomposition,  a  modification 
of  the  Gauss- Jordan  elimination  method,  more  suitable  fcr  computer  applications.  The 
matrix  of  coefficients  A*BA  is  transformed  into  the  product  of  two  matrices  L  and  U. 
where  L  is  a  lower  triangular  and  U  is  an  upper  triangular  matrix  with  Is  on  its  diagonal. 
The  advantage  is  that  storage  space  is  economized  and  the  ability  to  solve  the  system  of 
equations  with  new  righthand-side  vectors  A*BGd  (i.e.,  the  required  gain  contours  Gd)  can 
be  achieved  with  great  economy  of  effort.  The  number  of  arithmetic  operations  to  obtain 
the  solution  corresponding  to  each  A*BGd  is  the  same  as  to  multiply  an  N  x  M  matrix  by 
an  M-component  vector.  Since  both  magnitude  and  phase  of  the  gain  are  specified  with 
this  method,  it  is  useful  when  phase  tapering  (i.e.,  adding  a  fixed  phase  offset  between 
singlet  beams)  is  desired. 

3.4.2  Algorithm  2:  Minimum  Mean  Square  Error  Solution  for  Magnitude-Only  Gain 
Contours 

A  second  approach  to  computing  the  beam  weight  vector  is  to  specify  the  gain  by 
magnitude  only  and  to  minimize  the  weighted  mean-square-error  given  by 


I*2!  -<|G,|  -  |Gd|)TB(|Ga|  -  |Gj) 
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A  functional  minimization  of  |  c2 1  using  the  Davidon-Fletcher-Powell  (DFP)  algorithm 
can  now  be  employed.  This  method  is  superior  to  the  first  if  only  the  magnitude  of  the 
gain  is  desired.  Since  the  phase  at  each  point  of  the  desired  gain  contour  is  unspecified 
with  this  method,  an  additional  degree  of  freedom  exists  over  the  first  method  for 
determining  a  solution.  Of  course,  the  phase  of  each  component  of  the  desired  weight 
vector  will  still  be  of  critical  importance  in  establishing  any  desired  pattern  nulls. 
However,  due  to  the  gradient  search  technique  employed  with  this  method,  computational 
time  may  be  greater  than  that  of  algorithm  1. 

3.5  VERIFICATION  OF  ALGORITHM  1 

Two  tests  were  performed  using  the  first  algorithm  described  in  order  to  determine 
the  accuracy  of  the  solution  and  to  verify  that  the  software  is  correct.  As  discussed  in 
Section  3.1,  this  algorithm  minimizes  the  weighted  mean  square  error  when  the  desired 
gain  values  are  specified  as  complex  numbers  (magnitude  and  phase).  For  these  tests,  it 
was  assumed  that  all  gain  values  are  of  equal  importance.  Therefore,  the  weighting 
matrix  B  was  set  equal  to  the  identity  matrix. 

3.5.1  Initial  Test 

An  approximation  to  the  beam  pattern  of  each  singlet  beam  was  based  on  that  of  a 
uniformly-illuminated  circular  aperture.  The  directivity  pattern  is  given  by: 


E(u)  *  2na2  J,(u)/u 


where 


radius  of  the  circular  aperture 


(2ira/X)sin0 

transmission  wavelength 

angle  from  antenna  boresight  (the  look  angle) 


first-order  Bessel  function 


Figure  3-1.  Boresight  Pattern  of  6 I-Beam  MBR  Antenna 
Superimposed  on  Earth 


To  determine  the  gain  from  each  of  the  61  beams  in  the  MBR,  the  angle  0  was 
computed  as  the  angular  distance  from  singlet  beam  boresight  coordinate  to  the 
azimuth/elevation  coordinate  of  interest.  Figure  3-1  shows  the  boresight  pattern  of  the 
61-beam  MBR  antenna  superimposed  on  the  earth.  The  concentric  circles  represent  the 
half  power  (3  dB)  beamwidth  of  each  singlet  beam.  Since  the  DSCS  III  MBR  is  1.17 
meters  in  diameter  and  assuming  the  transmission  wavelength  X  to  be  0.0375  meters 
corresponding  to  a  transmission  frequency  of  8  GHz,  the  3-dB  beamwidth  of  a  singlet 
beam  can  be  computed.  The  result  is  a  beamwidth  of  approximately  2.25°  diameter.  The 


azimuth/elevation  coordinate  of  each  boresight  now  can  be  computed  using  the  center 
beam  boresight  located  at  0°  azimuth/O0  elevation  as  reference.  The  magnitude  of  the 
singlet  gain  for  the  center  beam  of  the  MBR  (beam  #31)  vs  azimuth  angle  at  a  fixed 
elevation  angle  of  0  degrees  is  shown  in  Figure  3-2. 

A  singlet  data  matrix  was  generated,  using  the  above  approximation  (an  IMSL  library 
routine  was  used  to  compute  the  Bessel  function),  consisting  of  the  full  earth  coverage 
area  of  ±9°  azimuth/elevation  (0.2°  granularity)  from  the  boresight  of  the  center  beam  of 
the  MBR.  This  is  equivalent  to  superimposing  a  +9°  azimuth/elevation  grid  on  the 
boresight  pattern  of  Figure  3-1v  The  result  is  8281  points  of  interest  (gain  values)  on  the 
earth  surface  for  each  of  the  61  singlet  beams.  The  singlet  data  matrix  is  therefore  of 
size  8281  x  61. 

3.5.1.1  Results  of  Initial  Test 

A  desired  gain  vector  of  size  8281  x  1  was  generated  whose  elements  were  equal  to 
one  column  of  the  singlet  data  matrix.  That  is.  the  desired  gain  was  set  equal  to  that 
produced  by  a  single  active  beam.  The  computed  beam  weight  vector  consisted  of  one 
non-zero  element  with  a  weighting  of  one  for  the  beam  whos?  singlet  gain  was  equal  to 
the  desired  gain.  That  is,  to  achieve  the  desired  gain,  the  algorithm  disabled  all  beams  in 
the  MBR  except  for  a  unity  weight  on  the  beam  whose  gain  matched  that  of  the  desired 
gain.  This  was  the  expected  result  and  indicates  the  algorithm  to  be  correctly 
implemented. 

3.5. 1.2  Computation  Time  Required 

The  time  required  for  solution  can  be  considered  in  two  parts.  The  first  is  the  time 
required  to  generated  the  system  of  equations.  This  involves  multiplication  of  A*BA 
where  A  in  this  case  is  a  full  size  8281  x  61  singlet  data  matrix.  The  total  required  CPU 
time  was  3  hours.  The  second  is  the  time  required  to  solve  the  system  of  simultaneous 
equations  for  the  W  vector.  The  total  CPU  time  for  this  was  2  seconds.  For  a  given 
singlet  data  matrix  A,  which  is  developed  for  a  defined  set  of  contour  points  on  the 
earth's  surface,  the  multiplication  A*BA  needs  to  be  performed  only  once,  even  if  the  gain 
values  for  each  of  the  defined  contours  are  changed  (unless  the  importance  of  particular 
points  in  the  gain  contour  change,  requiring  a  change  in  the  B  matrix).  That  is,  if  the 
gains  Gd  of  a  given  contour  are  changed  in  successive  cases,  the  singlet  matrix  A 
remains  unchanged  and  successive  beam  weight  vectors  W  can  be  computed,  each 


solution  requiring  approximately  2  seconds  of  CPU  time.  Most  gain  contours  would  have 
many  fewer  points  than  8281  (the  maximum)  and  the  computation  of  A*BA  typically  would 
be  much  less  than  3  hours  of  CPU  time.  Furthermore,  for  cases  where  the  relative 
importance  of  given  user  locations  is  changed  (i.e.,  requiring  a  change  to  the  weighting 
matrix  B),  it  is  advantageous  to  the  user  that  gains  be  specified  only  for  those  points  that 
are  critical  to  the  mission  in  order  to  reduce  the  A*BA  computation  time.  Of  course,  for 
cases  where  the  exact  user  location  is  unknown  or  specified  as  an  operating  area  of 
interest,  a  sufficient  number  of  points  within  the  operating  area  must  be  included  within 
the  required  gain  contour.  In  practice,  for  a  given  set  of  contour  points,  A*BA  could  be 
stored  offline  on  disk  and  called  up  when  needed. 

3.S.2  Test  with  Actual  Gain  Contours 

To  test  Algorithm  1  with  realistic  desired  gain  contours,  an  actual  contour  pattern 
developed  for  CW  acceptance  tests  of  the  DSCS  III  A1  was  used.  This  contour  is  shown 
in  Figure  3-3.  Input  data  points  for  azimuth/elevation  angle  and  gain  level  were  obtained 
for  the  contours  given  by  "sampling"  every  0.2°  of  azimuth  (M  ■  900).  The  sampled 
contour  data  are  shown  in  Figure  3-4. 

The  desired  gain  vector  was  obtained  directly  from  the  sampled  contour  data. 

3.5.2.1  Results  Using  Ideal  Singlet  Data 

A  singlet  data  matrix  was  generated  for  the  points  of  interest  (contour  points)  using 
the  Bessel  function  approximation  described  previously.  Only  the  magnitude  of  the 
singlet  data  is  computed  from  this  approximation.  The  phase  is  assumed  to  be  zero. 
Since  only  the  magnitude  of  the  desired  gain  is  specified  by  the  contour  data,  the  phase 
of  the  gain  at  each  point  can  be  considered  arbitrary.  Since  the  phase  associated  with 
the  singlet  data  approximation  was  assumed  to  be  zero,  the  phase  of  the  gain  was  also 
set  to  zero.  A  beam  weight  vector  was  computed  with  the  above  test  data  using 
algorithm  1.  The  resultant  contour  gain  values  for  the  points  of  interest  were  then 
computed  by  premultiplying  the  computed  beam  weight  vector  by  the  singlet  data  matrix. 
A  line  graph  of  the  resultant  gain  values  for  each  desired  contour  level  versus  data  point 
is  shown  in  Figure  3-5.  The  resultant  gain  values  for  desired  16-dB  points  show  the  least 
variation  of  the  three  levels  of  interest  (approximately  H  dB).  The  resultant  gain  values 
for  the  11 -dB  desired  points  exhibit  the  largest  variation. 


To  compare  the  desired  and  resultant  contour  patterns  it  was  necessary  to  compute 
the  resultant  gain  distribution  over  the  full  ±9°  azimuth/elevation  grid  and  plot  the 
contour  levels  of  interest.  The  resultant  gain  distribution  was  computed  by  premultiplying 
the  beam  weight  vector  by  the  full  8281  x  61  singlet  data  matrix. 

A  simple  contour  plotting  program  was  written  to  generate  the  resultant  contour 
levels  of  interest.  This  program  is  designed  to  scan  the  ±9°  azimuth/elevation  grid  in 
both  azimuth  and  elevation  and  to  mark  points  where  transitions  in  a  gain  level  occur 
across  levels  of  interest.  The  result  is  a  series  of  points  indicating  transitions  that  can  be 
connected  to  form  gain  contours. 

The  desired  16-dB  gain  contours,  obtained  directly  from  the  sampled  data,  are  shown 
in  Figure  3-6.  The  resultant  16  dB  contour  computed  from  the  algorithmically  determined 
beamweighting  vector  is  shown  in  Figure  3-7.  When  the  resultant  contour  is  overlaid  on 
the  desired  one,  it  can  be  seen  that  certain  areas  are  matched  quite  closely  while  others 
are  not.  Due  to  the  complexity  of  the  16-dB  contour  and  the  fact  that  an  approximation 
to  the  singlet  data  was  used,  an  exact  match  between  desired  and  actual  contours  was 
not  expected.  Similarly,  the  desired  and  resultant  14-dB  concurs  are  shown  in  Figures 
3-8  and  3-9.  respectively.  The  14-dB  contour  is  much  simpler  than  the  16-dB  and  a 
closer  match  is  seen  between  the  desired  and  actual  patterns.  Finally,  the  desired  and 
resultant  11-dB  contours  are  shown  in  Figures  3-10  and  3-11,  respectively.  This  is  the 
simplest  contour  and  shows  the  closest  match  between  the  desired  and  actual  patterns. 

3.S.2.2  Results  Using  Actual  Singlet  Data 

The  actual  singlet  data  were  obtained  and  a  new  beam  weight  vector  was  computed. 
The  actual  singlet  data  comprise  a  complex  vector  (i.e.,  in-phase  and  quadrature)  with 
components  that  represent  the  magnitude  and  phase  of  the  MBR  gain  per  beam  at  each 
point  on  the  earth  with  unity  beamweights  The  normalized  magnitude  of  the  gain  for  the 
center  beam  of  the  MBR  (beam  #31)  vs  azimuth  angle  at  an  elevation  of  0  degrees  is 
shown  in  Figure  3-12.  This  can  be  compared  with  Figure  3-2  which  represents  an 
approximation  to  the  actual  singlet  data.  Figure  3-13  shows  the  corresponding  phase 
response  confined  to  the  range  -n  to  it  (i.e,  plotted  modulo  2ir).  For  comparison,  the 
singlet  gain  and  phase  of  the  edge  beams  at  an  elevation  angle  of  0  degrees  (i.e.,  beams 
27  and  35)  are  shown  in  Figures  3-14  thru  3-17.  Of  interest  is  the  difference  in  phase 


8 


r. 

r‘ 


22 


SW  S3*  8_ 1 


ELEVATION  ANGLE 


angle  across  the  main  gain  lobe  between  the  three  beams  shown.  This  phase  angle 
difference  is  due  to  the  fact  that  all  beam  feed  horns  are  not  at  the  MBA  reflector  focal 
point. 

Since  no  phase  information  was  associated  with  the  desired  gain  contours,  the  phase 
of  the  desired  gain  at  each  point  of  interest  was  assigned  a  value  equal  to  the  phase  of 
the  vector  sum  of  the  singlet  data  for  the  61  beams  at  the  point  of  interest  on  the  earth's 
surface,  i.e.,  the  natural  phase  response  of  the  aperture  at  all  points  of  interest  on  the 
earth’s  surface.  In  other  words,  the  phase  assigned  to  a  desired  gain  point  M  is  the 
phase  of  the  complex  sum  of  row  M  of  the  singlet  data  matrix.  In  equation  form  this  is 
given  by: 

0M  -  tan-’f  l  0M  /  l  oM  J  3.9 

i*i  1  i»i  1 

where,  aM  3  real  part  of  singlet  data  for  the  ith 

1  beam  at  point  M 

8m  =*  imaginary  part  of  singlet  data  for  the  i,h 
1  beam  at  point  M 

The  required  beamweight  vector  was  computed  using  algorithm  1,  and  the  resultant 
contour  gain  values  for  the  points  of  interest  were  computed  using  Equation  3.4  where  A 
represents  the  actual  singlet  data  matrix.  The  beamweight  vector  W  (without  scaling  of 
singlet  data)  is  given  in  Table  3-1.  A  line  graph  of  the  resultant  gain  values  for  each 
desired  contour  level  versus  data  point  is  shown  in  Figure  3-18.  Comparison  of  Figure 
3-18  (obtained  with  the  actual  singlet  data)  and  Figure  3-5  (obtained  with  idealized  singlet 
data)  indicates  a  much  improved  capability  to  provide  a  contour  match. 

As  in  the  previous  section,  to  compare  the  desired  and  resultant  contour  patterns  it  is 
necessary  to  compute  the  resultant  gain  distribution  over  the  full  ±9°  azimuth/elevation 
grid  and  plot  the  contour  levels  of  interest.  The  resultant  gain  distribution  is  computed 
by  premultiplying  the  beam  weight  vector  W  by  the  full  8281  x  61  singlet  data  matrix. 

The  resultant  16  dB  contour  computed  from  the  new  beam  weight  vector  (using  the 
actual  singlet  data)  is  shown  in  Figure  3-19.  The  14  dB  and  II  dB  contours  are  shown  in 
Figures  3-20  and  3-21  respectively.  The  resultant  contours  are  much  closer  to  the 
corresponding  desired  contours  when  using  the  actual  singlet  data  than  those  obtained 
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Table  3-1.  Computed  Beam  weight  Vector  for  MBR  Contour 
Pattern  used  in  CW  Tests  -  no  scaling 


beam  no. 

REAL 

IMAG. 

BEAM  NO. 

REAL 

XMAG. 

1 

0.0009860 

0.0000213 

50 

0.0009087 

0.0000237 

A 

2 

0.001022S 

-0.0000157 

51 

0.0008072 

0.0001820 

• 

3 

0.0011401 

0.0000170 

52 

0.0014895 

-0.0000539 

4 

0.0008570 

0.0000529 

53 

0.0009990 

0.0000242 

5 

0.0009027 

-0.0000442 

54 

0.0010151 

0.0000250 

6 

0.0008050 

0.0001552 

55 

0.0011112 

-0.0000395 

7 

0.0011919 

0.0001128 

56 

0.0008681 

0.0001346 

8 

0.0010420 

0.0000685 

57 

0.0008516 

0.0000924 

9 

0.0011030 

-0.0000786 

58 

0.0008251 

0.0002572 

10 

0.0008444 

0.0000667 

59 

0.0009668 

-0.0000595 

11 

0.0008192 

0.0001517 

60 

0.0007636 

0.0001058 

12 

0.0010067 

0.0000499 

61 

0.0007855 

0.0004017 

13 

0.0011103 

-0.0000284 

14 

0.0010742 

0.0000169 

k 

15 

0.0011252 

-0.0000277 

16 

0 . 0009145 

0.0001107 

17 

0.0012287 

-0.0001138 

18 

0.0006936 

0.0000405 

19 

0.0010486 

0.0000109 

20 

0.0011637 

-0.0001128 

21 

0.0009240 

0.0001289 

22 

0.0011397 

0.0000333 

23 

0.0010846 

-0.0000394 

24 

0.0010905 

0.0000255 

25 

0.0009402 

0.0000118 

26 

0.0008754 

-0.0000242 

27 

0.0012436 

0.0000583 

28 

0.0011944 

-0.0000604 

29 

0.0009949 

0.0000832 

30 

0.0010289 

-0.0000555 

31 

0.0010878 

0.0000525 

32 

0.0010371 

-0.0000462 

33 

0.0011702 

0.0000122 

34 

0.0010346 

-0.0000051 

35 

0.0011323 

0.0000431 

36 

0.0009555 

0.0001012 

37 

0.0011110 

-0.0000553 

38 

0.0010650 

0.0000085 

39 

0.0010713 

-0.0000033 

40 

0.0012437 

-0.0000405 

41 

0.0010192 

0.0000443 

42 

0.0010721 

-0.0000286 

43 

0.0007444 

0.0003133 

44 

0.0007516 

-0.0000019 

45 

0.0010580 

0.0000765 

46 

0.0008805 

0.0001184 

47 

0.0008926 

0.0000659 

48 

0.0008499 

0.0002212 

49 

0.0011781 

-0.0000602 

with  the  approximate  singlet  data.  This  is  because  the  desired  gain  contours  were 
originally  generated  using  actual  singlet  data. 

3.5.2.3  Computation  Time  Required 

A  major  advantage  to  this  method  is  that  large  dimension  systems  can  be  solved  with 
relatively  short  computation  time.  Specifically,  for  the  test  using  realistic  desired 
contours,  the  following  computation  times  were  observed:  for  M  *  900:  A*BA  *  1.5 
minutes  CPU;W  vector  *  2  seconds  CPU. 

3.5.3  Test  with  Jammer  Nulling 

Of  particular  interest  is  the  capability  to  null  a  specific  area  that  may  contain  a 
jamming  signal.  To  test  this  capability,  it  was  decided  to  modify  the  desired  contour 
pattern  to  include  a  null.  The  11  -dB  closed  contour  in  the  vicinity  of  1  degree  azimuth/5 
degrees  elevation  was  arbitrarily  chosen  as  the  new  null  (see  Figures  3-10  and  3-4).  The 
minimum  separation  between  this  contour  and  the  adjacent  14  dB  contour  is 
approximately  1  degree  (or  44%  of  one  beamwidth).  Since  the  null  area  is  of  particular 
importance,  the  diagonal  weighting  matrix  B  of  Equation  3.6  was  employed  (other  than  the 
identity  matrix).  The  values  of  the  diagonal  elements  of  B  were  computed  as  an  inverse 
function  of  the  number  of  points  defining  the  null  contour. 

3.5.3.1  Results  for  Required  Nulling  of  14  dB/degree 

As  an  initial  test  of  nulling  with  algorithm  1,  the  null  contour  level  was  set  to  0  dB. 
Since  the  minimum  separation  between  this  contour  and  the  adjacent  14  dB  contour  is 
approximately  1  degree,  this  represents  a  null  "slope''  of  14-dB/degree.  The  null  contour 
is  of  particular  importance  and  should  be  weighted  more  heavily  in  the  determination  of  a 
beamweight  vector  used  to  match  the  desired  contours.  One  method  of  weighting  is  to 
weight  the  null  contour  inversely  proportional  to  the  relative  number  of  points  defining  it. 
Specifically,  the  null  contour  consists  of  14  points  out  of  a  total  of  900  defining  the 
desired  gain  contours.  In  this  case  it  was  decided  to  weight  the  null  contour  equally  as 
important  as  the  combined  importance  of  the  remaining  contours.  That  is,  50%  of  the 
total  weighting  was  assigned  to  the  null  contour  and  50%  assigned  to  the  remaining 
contours.  Therefore,  the  value  of  the  diagonal  elements  of  the  B  matrix  corresponding  to 
the  null  contour  points  is  given  by  0  5/14.  The  value  of  the  remaining  diagonal  elements 
of  the  B  matrix  corresponding  to  the  remaining  contour  points  is  given  by  0.5/886.  The 


beamweight  vector  was  computed,  and  the  resultant  gain  contours  were  determined  as 
before.  The  beamweight  vector  is  given  in  Table  3-2.  The  resultant  16-dB  contour  is 
shown  in  Figure  3-22.  Very  little  change  resulting  from  the  effect  of  the  jammer  null  was 
observed  in  this  contour  from  that  of  Figure  3-19.  The  resultant  14  and  11  dB  contours 
are  shown  in  Figures  3-23  and  3-24,  respectively.  A  noticeable  distortion  has  occured  in 
the  vicinity  of  the  jammer  null  on  the  14-dB  contour  plot.  This  is  due,  in  part,  to  the 
limited  resolution  capability  of  the  MBA  to  discriminate  between  users  and  interferes 
separated  by  less  than  one  beamwidth  (here  less  than  44%  of  one  beamwidth).  In 
addition,  a  new  11 -dB  contour  appears  around  the  jammer  null  locations  as  expected. 
The  desired  and  resultant  0  dB  contours  are  shown  in  Figures  3-25  and  3-26, 
respectively. 

3.5.3.2  Results  for  Required  Nulling  of  20  dB/deg. 

To  further  test  algorithm  1  with  nulling,  the  null  contour  described  above  was  reduced 
to  -6  dB.  This  represents  a  null  slope  of  approximately  20  dB/degree  and  a  requirement 
of  a  ring  null  that  may  be  near  the  theoretical  maximum  resolution  capability  of  the  MBR. 
The  weighting  on  the  null  in  terms  of  relative  importance  (B  matrix)  was  increased  by  a 
factor  of  10  over  the  0  dB  case  described  above. 

The  beamweight  vector  was  computed  and  the  resultant  contours  were  drawn.  The 
new  beamweight  vector  for  the  -6  dB  nulling  case  is  given  in  Table  3-3.  The  resultant 
16,  14  and  11-dB  contours  are  shown  in  Figures  3-27  thru  3-29.  A  distortion  similiar  to 
that  observed  with  the  0  dB  nulling  case  above  is  also  observed  in  these  contours.  The 
resultant  0  dB  contour  is  shown  in  Figure  3-30  for  reference  with  Figure  3-26.  The 
desired  and  resultant  -6  dB  contours  are  shown  in  Figures  3-31  and  3-32,  respectively. 
Only  a  single  point  was  obtained  for  the  desired  -6  dB  contour,  as  indicated  by  the  arrow 
in  Figure  3-32.  This  may  be  an  indication  of  the  resolution  capabilities  of  the  MBR  to 
achieve  the  nulling  depth  specified  in  this  case.  Further  work  is  recommended  to 
determine  if  this  result  can  be  improved  using  phase  tapering  techniques. 


Table  3-2.  Computed  Beamweight  Vector  for  MBR  Contour 
Pattern  with  0  dB  Null  Contour  -  no  scaling 


V. 

BSAK  NO. 

REAL 

IMAG. 

BEAM  NO. 

REAL 

IMAG. 

1 

0.0009822 

0.0000155 

49 

0.0011890 

-0.0000339 

B, 

*  > 

2 

0.0010547 

-0.0000188 

50 

0.0008801 

0.0000030 

3 

0.0011074 

0.0000678 

51 

0.0008132 

0.0001186 

s/ 

4 

0.0008205 

0.0000715 

52 

0.0014282 

-0.0000519 

5 

0.0009385 

0.0000216 

53 

0.0010347 

-0.0000529 

V, 

6 

0.0007899 

0.0001403 

54 

0.0006743 

0.0000147 

v* 

7 

0.0011520 

0.0001354 

55 

0.0012186 

0.0000335 

8 

0.0010344 

0.0000378 

56 

0.0008794 

0.0001491 

v. 

9 

0.0011591 

-0.0000974 

57 

0.0008233 

0.0000738 

10 

0.0008333 

0.0000611 

58 

0.0008948 

0.0003108 

*’  ’ 

11 

0.000 7858 

0.0001163 

59 

0.0010461 

-0.0002131 

12 

0.0010016 

0.0000774 

60 

0.0006471 

-0.0000587 

13 

0.0011327 

-0.0000254 

61 

0.0007627 

0.0006237 

ir 

14 

0.0010945 

-0.0000003 

15 

0.0011035 

-0.0000305 

16 

0.0008424 

0.0000859 

17 

0.0012301 

-0.0000819 

18 

0.0006837 

0.0000556 

19 

0.0010566 

0.0000108 

20 

0.0011484 

-0.0001476 

i 

21 

0.0009055 

0.0001504 

22 

0.0011643 

0.0000746 

23 

0.0012003 

-0.0000264 

24 

0.0011289 

0.0000416 

25 

0.0009066 

0.0000059 

26 

0.0009029 

-0.0000157 

r 

27 

0.0013783 

0.0000723 

■t 

28 

0.0011284 

-0.0000040 

29 

0.0010261 

0.0000809 

30 

0.0010361 

-0.0000832 

31 

0.0009513 

0.0000987 

*. 

32 

0.0009280 

-0.0001767 

33 

0.0011828 

-0.0000013 

34 

0.0010419 

-0.0000054 

35 

0.0011403 

-0.0000002 

36 

0.0009614 

0.0001086 

37 

0.0011550 

-0.0001084 

38 

0.0010194 

-0.0000446 

39 

0.0011663 

-0.0000246 

40 

0.0014861 

0.0000548 

41 

0.0010782 

0.0001515 

42 

0.0010355 

-0.0000190 

■ 

43 

0.0007815 

0.0002940 

$ 

44 

0.0007633 

0.0000214 

45 

0.0010299 

0.0000765 

• 

46 

0.0009337 

0.0000723 

47 

0.0004661 

0.0002049 

.*/ 

48 

0.0005515 

0.0002970 

Figure  3-22.  Resultant  16  dB  Contour 


3-25.  Desired  0  dB  Contour 
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Table  3-3.  Computed  Beam  weight  Vector  for  MBR  Contour 
Pattern  with  -6  dB  Null  Contour  -  no  scaling 


BEAL 


0.0009866 
0.0010864 
0.0011173 
0.0007935 
0.0009666 
0.0007774 
0.0011327 
0.0009970 
0.0012004 
0.0008207 
0.0007496 
0.0009792 
0.0011512 
0.0011286 
0.0011049 
0.0007291 
0.0012621 
0.0006555 
0.0010660 
0.0011505 
0.0008870 
0.0011201 
0.0 012796 
0.0011410 
0.0009030 
0.0009133 
0.0014045 
0.0010822 
0.0010451 
0.0010560 
0.0008559 
0.0008707 
0.0011944 
0.0010399 
0.0010323 
0.0010064 
0.0011683 
0.0010315 
0.0012175 
0.0016190 
0.0010620 
0.0010273 
0.0007603 
0.0007292 
0.0010208 
0.0009285 
0.0001733 


ZMAG. 


0.0000029 
-0.0000256 
0.0000822 
0.0001345 
0.0000492 
0.0001120 
0.0001098 
0.0000510 
-0.0001517 
0.0000529 
0.0001111 
0.0000767 
0.0000169 
-0.0000226 
-0.0000396 
0.0001486 
-0.0000762 
0.0000717 
0.0000253 
-0.0001747 
0.0001331 
0.0001330 
-0.0000295 
0.0000391 
0.0000267 
-0.0000441 
0.0000132 
-0.0000008 
0.0001260 
-0.0001369 
0.0000883 
-0.0002431 
-0.0000209 
-0.0000265 
•0.0000179 
0.0000965 
-0.0001438 
•0.0000697 
0.0000427 
0.0001375 
0.0002229 
0000427 
0002423 
0000379 
0001435 
0.0000261 
0.0001368 


0 

0, 

0, 

0, 


BEAM  NO. 

BEAL 

1MAG. 

48 

0.0003847 

0.0002422 

49 

0.0011978 

-0.0000990 

50 

0.0008470 

0.0000374 

51 

0.0008031 

0.0000839 

52 

0.0014658 

-0.0001177 

53 

0.0009403 

0.0000687 

54 

0.0004690 

0.0002359 

55 

0.0010895 

0.0001341 

56 

0.0009483 

0.0001695 

57 

0.0008236 

0.0001543 

58 

0.0009101 

0.0002669 

59 

0.0011247 

-0.0004103 

60 

0.0004667 

-0.0001720 

61 

0.0006813 

0.0005476 
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Figure  3-27.  Resultant  16  dB  Contour  — 6  dB  null  at  1  deg. 
azimuth  /  5  deg.  elevation 


z 

o 

I- 

< 

> 

Ld 

_l 

Ld 


-3-  ' 

-5- 

—  7- 

—  9~)  r  |  ,  |  r-r-r  | 

-9  -7  -5  —3  — 


3  5 


AZIMUTH  ANGLE  (DEG.) 


52 


>  V 

u*-'> 


$8 


v.v 


E.%  /•  »*•  -** y* *'*>''*  »'*  •**  /* »** «**  *%*  a  >%  «*•  *  • » *.»  -  » •  *'  .  ."»•  '•  , 


■  V*  *\  •".  *.  -*•/  •  ■  \ 

iMiMiiiiAiHA 


V 


Figure  3-31  Desired  -  6  dB  Contour 


3.6  VERIFICATION  OF  ALGORITHM  2 

The  MSE  solution  for  magnitude-only  gain  contours  has  been  implemented  in 
software.  Initial  tests  have  been  performed  using  the  MBR  contour  pattern  described  in 
Section  3.5.2  as  the  desired  contour  and  the  solution  beamweight  vector  determined  by 
algorithm  1  as  the  initialization  for  the  Davidon-Fletcher-Powell  algorithm. 

3.6.1  Results  using  Beamweight  Solution  from  Algorithm  1  -  Non-Nulling  Scenario 
The  beamweight  vector  solution  obtained  using  algorithm  1  for  the  non-nulling 

scenario  with  actual  singlet  data  (Table  3-1)  was  used  as  input  to  the  Davidon-Fletcher- 
Powell  algorithm.  By  providing  an  initial  guess  to  the  algorithm  that  is  close  to  the 
desired  solution,  computational  time  can  be  reduced  and  an  improved  solution  is 
obtained.  Due  to  the  increased  computational  time  involved  in  applying  this  algorithm,  it 
is  more  suitable  for  "fine  tuning"  of  resultant  contour  patterns  to  meet  some  desired 
requirements.  A  beamweight  vector  for  the  desired  MBR  contour  pattern  was  obtained 
and  is  given  in  Table  3-4.  The  resultant  16,  14  and  11  dB  contour  patterns  are  shown  in 
Figures  3-33  thru  3-35.  Significant  improvement  can  be  seen  in  the  resultant  contours 
over  the  corresponding  contours  of  Figures  3-19  thru  3-21. 

3.6.2  Computation  Time  Required 

Since  this  method  involves  a  gradient  search  technique,  the  computational  time  is 
significantly  longer  than  with  algorithm  1.  Specifically,  for  the  scenario  described  above 
the  CPU  time  required  to  arrive  at  a  solution  was  15  minutes  55.8  seconds  using  the 
solution  beamweight  vector  determined  by  algorithm  1  as  the  initialization  (seed  value) 
for  the  Davidon-Fletcher-Powell  algorithm. 

3.7  CONCLUSIONS  AND  SUGGESTIONS  FOR  FUTURE  WORK 

3.7.1  Conclusions 

The  approach  pursued  here  for  determining  the  beamweight  vector  W  (i.e., 
algorithm  1)  looks  promising  for  use  in  the  DNPS  because  of  the  speed  with  which  a 
solution  is  obtained  for  a  given  singlet  data  matrix.  As  stated  previously,  the  required 
weight  vector  W  computation  of  A  BA  needs  to  be  performed  only  once  even  if  the 
contour  gain  levels  are  changed,  as  long  as  contour  area  definitions  and  weighting  matrix 


Table  3-4.  Computed  Beamweight  Vector  for  MBR  Contour 
Pattern  after  Functional  Minimization  -  no  scaling 


CAM  NO. 

RIAL 

XMAG. 

1 

0.0009514 

-0.0000077 

2 

0.0010177 

-0.0000172 

3 

0.0011505 

0.0000312 

4 

0.0008298 

0.0000301 

S 

0.0009089 

-0.0000190 

6 

0.0007561 

0.0001220 

7 

0.0012142 

0.0001448 

a 

0.0010451 

0.0000569 

9 

0.0011122 

-0.0000715 

10 

0.0008494 

0.0000864 
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B  remain  fixed  for  a  given  set  of  geographic  contours.  Large  systems  can  be  solved  with 
very  good  results,  as  shown.  If  contour  area  definitions  are  changed  in  only  a  small  area, 
a  partial  beamweight  solution  could  be  performed  for  the  area  in  question.  The  resulting 
beamweights  could  be  inserted  into  the  existing  W  vector  to  obtain  the  new  resultant 
contours. 

3.7.2  Suggestions  for  Future  Work 

It  is  recommended  that  further  testing  of  algorithm  1  using  measured  singlet  data  be 
performed.  The  issue  of  generating  a  partial  beamweight  solution  for  small  contour  areas 
that  have  undergone  a  change  in  requirements  could  be  investigated.  Also,  algorithm  1 
will  be  of  further  interest  for  tests  with  phase  tapering,  since  the  solution  considers  both 
magnitude  and  phase  of  the  gain. 

The  functional  minimization  approach  (algorithm  2)  can  further  be  tested  with  the 
nulling  scenarios  described  above  to  improve  upon  the  results  obtained  thus  far. 
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A.1  Overview 

The  OOCS  has  been  enhanced  by  the  addition  of  the  adaption  subsystem  to  the  ONPS. 
The  adaption  subsystem  produces  the  largest  supportable  subscenario  of  the  active  DNPS 
scenario.  The  subsystem  generates  network  configurations  that  satisfy  arbitrary  jammer, 
terminal  excessive  power  requirements  and/or  equipment  failure  constraints,  in 
accordance  with  the  user-specified  adaption  criteria.  The  active  scenario  (the  input  to 
the  adaption  subsystem)  contains  definitions  of  terminals,  frequency  hop  links,  FDMA  links, 
ECCM  links/circuits,  jammers,  subnets,  satellite  characteristics  and  the  adaption  criteria. 
The  subscenario  (output  of  the  adaption  subsystem)  is  based  on  the  combination  of 
constrained  traffic,  prioritized  ranking  of  unconstrained  traffic  elements  and  unconstrained 
traffic  processing  (an  iterative  process). 

To  support  this  integration  the  following  areas  required  changes  to,  or  added 
interfaces  with,  DOSS/DNPS: 

•  On-Line  Static  Database  Loader 

•  Scenario  definition 

•  Traffic  adaption 

•  Report  generation. 

Two  major  requirements  were  added  to  the  existing  DOSS  by  the  ENAM: 

•  The  capability  to  temporarily  ignore  traffic  elements  in  the  network 
calculations 

•  The  capability  to  constrain  traffic  elements  into  the  network,  regardless  of 
power  requirements. 


A  major  goal  in  the  addition  was  to  provide  the  capability  to  determine  the  maximum 
supportable  network,  given  a  set  of  operator-entered  constraints.  The  Traffic  Adaption 
subsystem  was  added  to  support  this  requirement. 


A.2  Purpose  of  Testing 

The  major  goal  in  the  testing  effort  is  the  verification  of  output  continuity  in  the 
transition  from  OOSS  version  2.1  to  DNPS  version  3.1.  This  involved  identification  of  a 
typical  user  scenario  and  generation  of  output  from  the  subsystems  of  both  versions  of 
the  software.  The  output  is  analyzed  to  determine  if  the  new  software  is  still  producing 
acceptable  results.  Should  the  software  produce  inconsistent  output  an  effort  will  be 
made  to  identify  the  problem  and,  if  possible,  create  a  'work  around'  solution  (one  that 
does  not  require  the  software  to  be  modified).  An  additional  goal  in  the  testing  effort  is 
the  establishment  of  baseline  testing  procedures  and  scenarios  for  the  ECCM  Adaption 
subsystem.  These  testing  procedures  for  output  data  continuity  and  the  ECCM  Adaption 
subsystem  will  aid  in  the  future  transitions  between  version  of  operational  software. 

A.3  Testing  Sequence  Overview 

The  following  steps  are  typical  of  the  testing  process.  Specific  scenarios  will  modify 
the  required  test  steps  because  of  the  data  contained  in  the  scenario.  An  example  of  this 
is  'jammer  nulling';  the  menu  that  invokes  this  algorithm  will  be  displayed  only  when  a 
jammer  is  present  in  the  scenario  being  tested.  The  specific  ;?st  steps  required  for  each 
scenario  are  detailed  below. 

1.  Retrieve  Scenario  -  Loads  the  desired  scenario  to  test  into  the  active 
database. 

2.  Analysis  Support  -  Calculates  the  directive  gains  for  the  earth  coverage 
antennas,  earth-relative  and  satellite-relative  terminal/jammer  azimuth  and 
elevation,  slant  ranges  to  terminals,  path  loss  (based  on  the  center  frequency), 
argument  of  perigee,  semi-major  axis  and  range  rate  data  (when  the  sub- 
point  is  calculated). 

•  Initialize  constants 

•  Verify  satellite  location 

•  Start  analysis 

3.  Allocation  -  Generates  or  selects  all  the  required  network  parameters  for  the 
network  performance  analysis. 

•  All  options  off  except  summary  report  and  GOA  pointing 


Start  allocation 


4.  Network  Performance  -  Performs  the  forward  link  calculations  to  support  the 
defined  scenario. 


•  All  options  off  except  summary  report 

*  Start  network  performance  processing. 

5.  Report  Generation  -  Generates  various  types  of  reports  of  the  expected 
performance  of  the  active  scenario.  The  following  reports  are  typical: 


*  All  links  and  all  channels 

*  Satellite  analysis 

*  Terminal  directive  gains 

*  Beam  weights 

6.  Adaption  -  Generates  network  configurations  that  satisfy  arbitrary  jammer, 
excessive  power  requirements  and/or  equipment  failure  constraints,  in 
accordance  with  the  user-specified  adaption  criteria  Adaption  is  run  when 
the  active  scenario  cannot  achieve  a  realizable  network. 

*  Use  allocation  beam  weights 

*  All  default  settings 

*  Select/Modify  Operator  Interrupt  Criteria 

a.  Start  Adaption 

Create  the  following  reports  : 

o  Traffic  Ranking  Report 
o  Network  Performance 
o  ECCM  Link  Summary 
o  Satellite  Analysis 

Verify  CCC'  are  included  in  the  network. 

b.  Continue  with  Adaption 
Create  the  following  reports  : 
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o  Traffic  Ranking  Report 
o  Network  Performance 
o  ECCM  Link  Summary 
o  Satellite  Analysis 

Verify  'IET'  are  included  in  the  network. 

c.  Continue  with  Adaption 

Create  the  following  reports  : 

o  Traffic  Ranking  Report 
o  Network  Performance 
o  ECCM  Link  Summary 
o  Satellite  Analysis 

Verify  RLL’  are  included  in  the  network. 
*  Set  breakpoint  option  1 

a.  Continue  with  Adaption 

Create  the  following  reports  : 

o  Traffic  Ranking  Report 
o  Network  Performance 
o  ECCM  Link  Summary 
o  Satellite  Analysis 
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A.4  Test  Scenario  One 


A.4.1  Scenario  Description 

Test  scenario  one  included  ECCM  links,  FH  traffic,  FDMA  links  and  a  definition  for  a 
jammer.  A  single  user  group  was  defined  and  the  priority  assigned  to  this  group  was 
'000002/  The  ECCM  circuits  of  the  ECCM  links  were  established  with  priorities  of 
'000002/  Data  rates  and  circuits  within  the  ECCM  links  were  varied  to  exercise  the 
software.  FDMA  links  were  spread  between  channels  1,  2,  3  and  4.  Modulation  and 
coding  type  also  were  varied.  The  number  of  FH  links  was  small  and  were  included  for 
completeness.  The  adaption  criteria  established  were  of  the  same  priority  (regardless  of 
criteria  type)  and  of  the  same  name. 


A.4.2  Scenario  One  Test  Steps 


Input  Description 

Username  Enter  username 
Password  Enter  password 

4  Scenario  Definition 

9  Mutiple  Scenarios 

2  Retrieve  A  Scenario 

5  Index  Of  Scenario 

8  Retrieve  Entire  Scenario 

Y  Verifies  Database  Reset 

Level-Up  Return  To  Scenario  Definition  Menu 

Level-Up  Return  To  Top  Level  DNPS  Menu 

5  Analysis  Support 

1  Initialize  Satellite  Constants 

6451  The  IRON  Of  The  Satellite 

4  List/Modify  Satellite  SSP 

4  Satellite  Longitude 

-135  Enter  Longitude  For  Satellite 

Level-Up  Return  To  Analysis  Support  Menu 

5  Perform  Satellite  Analysis 

Level-Up  Return  To  Top  Level  ONPS  Menu 

6  Allocation 

3  Channel  Gain  Setting  Option 

N  Auto  Gain  Prompt 

Y  Auto  Gain  Prompt 

OFF  Turns  Auto  Gain  Off 

Y  Auto  Gain  Prompt 

OFF  Turns  Auto  Gain  Off 

Y  Auto  Gain  Prompt 

OFF  Turns  Auto  Gain  Off 

Y  Auto  Gain  Prompt 

OFF  Turns  Auto  Gain  Off 

Y  Auto  Gain  Prompt 

OFF  Turns  Auto  Gain  Off 

4  GDA  Pointing  Option 

ON  Turn  Pointing  ON 

5  Downlink  MBX  Allocation  Option 

OFF  Turn  Option  Off 

Level-Up  Return  To  Allocation  Menu 

6  Uplink  M8R  Allocation  Option 

OFF  Turn  Oprtion  Off 

Level-Up  Return  To  Allocation  Menu 

7  Frequency  Hop  ALIocation  Option 

OFF  Turn  Option  Off 

1  Initiate  Network  Allocation  Processing 

Level-Up  ECCM  Allocation  Modification  Menu 


Password  prompt 
DOSS/DNPS  Top  level  menu 
Scenario  Definition  Menu 
Catalog  Of  Saved  Scenarios 
Prompt  To  Select  A  Scenario 
Options  For  Scenario  Loading 
Database  Rent  Prompt 
Scenario  Catj.og  Menu 
Scenario  Definition  Menu 
Top  Level  DNPS  Menu 
Analysis  Support  Menu 
Satellite  IRON  Prompt 
Analysis  Support  Menu 
Satellite  Subpoint  Position  Detail 
Logitude  Prompt 

Satellite  Subpoint  Position  Detail 
Analysis  Support  Menu 
Analysis  Support  Menu 
Top  Level  DNPS  Menu 
Allocation  Support  Menu 
Auto  Gain  Prompt  Channel  1 
Auto  Gain  Prompt  Channel  2 
Option  Select  Prompt 
Auto  Gain  Prompt  Channel  3 
Option  Select  Prompt 
Auto  Gain  Prompt  Channel  4 
Option  Select  Prompt 
Auto  Gain  Prompt  Channel  5 
Option  Select  Prompt 
Auto  Gam  Prompt  Channel  6 
Option  Select  Prompt 
Allocation  Support  Menu 
Option  Select  Prompt 
Allocation  Support  Menu 
Option  Select  Prompt 
MBX  Option  Menu 

Option  Select  Prompt 
MBR  Option  Menu 

Option  Select  Prompt 
Allocation  Menu 
GDA  Pointing  Algorithm 
Allocation  Menu 
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MBR  Modification* 
Jammer  Nulling  Algorithm 


Uplink  MBA  Allocation  Option 
Turn  Option  Off 
Beamweights  For  MBR 
Salact  ECCM  Beamweights 
Return  To  Allocation  Menu 
Initiate  Allocation  Processing 


Performance 
ACI  Effects  Option 
Turn  Option  Off 
Intermodulation  Option 
turn  Option  Off 

Initiate  Perf  Analysis  W/0  Margin  Leveling 

Top  Level  ONPS  Menu 

Utilities 

ECCM  Adaption 

Modify  Alloc/Parf  Processing  Flags 

Channel  Gain  Settings  Option 
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Output  To  Printer 
Report  Generation  Menu 
Link  Report* 
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A.4.3  Scenario  Analysis  and  Conclusions 

Due  to  the  computer  hardware  problems  at  the  DCEC  Reston  facility,  results  of  this 
effort  were  delayed.  Results  will  be  reported  under  follow-on  tasking. 

A.5  Test  Scenario  Two 

A.5.1  Scenario  Description 

Scenario  two  included  definitions  for  ECCM  links  and  FDMA  links.  Many  different  user 
groups  were  defined,  and  prioritization  of  these  groups  varied  from  '000000'  to  '999998'. 
Criteria  definitions  of  this  scenario  provided  for  the  software's  ability  to  select  links  of  the 
network  based  on  the  criteria  selected.  The  criteria  defined  within  the  scenario  were  for 
geographic  location,  user  classification,  data  rates  and  communications  classification. 
Link  definitions  in  the  scenario  provided  for  traffic  across  channels  1,  2,  3  and  4. 
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A.5.3  Scenario  Analysis  and  Conclusions 

Due  to  computer  hardware  problems  at  the  DCEC  Reston  facility,  results  of  this  effort 
were  delayed.  Results  will  be  reported  under  follow-on  tasking. 

A.6  User  Test  Scenario 


A.6.1  Scenario  Description 

The  user  scenario  provides  for  verification  of  output  of  different  versions  of 
DOSS/ONPS  software.  This  scenario  was  used  to  create  output  from  the  various 
subsystems  of  DNPS  of  two  versions  of  software.  This  output  is  used  for  verification  of 
output  continuity/integrity  between  versions.  The  scenario  calls  for  manipulation  of  data 
by  i  he  software  using  the  same  set  of  commands  that  the  author  normally  uses.  This 
scenario  was  established  as  a  feasibility  study  of  traffic  in  channel  1.  Although  the 
scenario  contains  definitions  for  links  in  other  channels,  the  scenario  was  primarily  used 
for  the  evaluation  of  channel  1  traffic. 


A.6.2  User  Scenario  Test  Steps 

Input  Description 

Username  Enter  username 

Password  Enter  password 

4  Scenario  Definition 

9  Mutiple  Scenarios 
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A.6.3  Scenario  Analysis 

Results  of  this  effort  will  be  reported  under  the  FY86  contract  tasking. 


A. 6.4  Conclusions 


Results  of  this  effort  will  be  reported  under  the  FY86  contract  tasking. 


A.7  OOSS/DNPS  Version  3.1  Problems  and  Conclusions  and  Recommendations 


A.7.1  Problems 

The  following  are  the  problems  encountered  during  the  testing  effort.  These  problems 
ranged  from  cosmetic  errors  to  software  logic  problems.  (Additionally,  significant 
hardware  problems/downtime  was  experienced  during  the  tests;  however,  these  problems 
are  expected  to  be  corrected  in  the  near  term.) 

*  Documentation  - 

There  is  insufficient  documentation  of  the  ECCM  Adaption  subsystem. 
Although  it  is  a  very  powerful  addition  to  the  DNPS  package,  more  complete 
documentation  of  this  subsystem  is  recommended. 

*  SSMA  Modem  Table  - 

When  a  modem  name  is  added  and/or  modified,  the  name  must  adhere  to  a 
strict  naming  convention.  This  naming  convention  is  critical  during  the 
automatic  creation  of  ECCM  links  that  support  a  newly  added  ECCM  terminal. 

One  of  the  following  is  recommended: 

o  The  naming  convention  be  documented  (e  g.,  AN/USC-28  vs.  USC-28) 

o  The  software  be  modified  so  that  the  modem  name  is  not  used  with 
program  logic. 

o  The  software  parse  the  modem  name  during  input,  if  a  modem  name  is 
critical  in  subsequent  program  logic,  then  the  software  should  test 
(parse)  the  input  for  a  valid  name.  By  preventing  incorrect  input  for  a 
name  field,  software  logic  failures  will  be  eliminated.  In  this  case, 
"AN/USC  28*  or  "AN/USC/28'  would  not  satisfy  the  name  required 
(AN/USC-28)  in  subsequent  software  logic  (although  similar  to  the 
required  name). 

*  Local  Loop  - 

Two  local  loops  were  unable  to  meet  predicted  margins  required  to  support 
the  downlink.  By  switching  the  dominant  link  to  RL1XXX  (from  RN1XXX)  the 
local  loop  was  included  in  the  network. 

*  Insufficient  Testing  of  the  Network  Control  Book  - 

Menu  errors  occurred  during  the  examination  of  the  Network  Configuration 
Book  (NCB). 
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Output  Generation  Message  - 

The  report  generation  message  is  issued  erroneously  when  a  Level-up  is 
commanded  to  abort  command.  The  Level-up  command  is  issued  at  the 
output  prompt  (0/P)  after  selecting  a  specific  report  type.  This  message  was 
noted  from  the  ECCM  Report  Generation  subsystem  under  the  following  report 
types: 

o  Terminal/Jammer  Directive  Gains  Summary 


o  ECCM  Allocation  Summary. 


A.7.2  Conclusions  and  Recommendations 

The  software  needs  more  rigorous  testing  prior  to  being  formally  accepted.  With  the 
inclusion  of  the  ECCM  subsystem,  major  areas  of  the  software  were  only  preliminarily 
evaluated/tested.  The  following  would  aid  in  the  testing  effort: 

•  Determine  the  Extent  of  Testing  - 

When  a  Software  User  Report  is  accepted  by  the  Configuration  Control  Board, 
the  scope  of  testing  should  then  be  established. 

•  Review  Code  Prior  to  Acceptance  Testing  - 
Desk  check  the  code  to  determine  the  impact  on  otner  areas  of  code.  This 
should  be  done  prior  to  starting  any  testing.  The  results  of  the  review  will 
determine  what  sections  need  to  be  exercised. 

•  Establish  Minimal  Acceptance  Test  - 

A  minimal  set  of  tests  should  be  established  and  used  for  all  versions  of  the 
software  prior  to  release. 

•  Establish  Automated  Acceptance  Tests  - 
Through  the  use  of  automated  test  procedures,  the  software  can  be  tested  by 
using  a  specific  set  of  'canned'  tests.  This  will  prevent  the  introduction  of 
new  problems. 

•  Breakpoint  Type/Number  - 

During  the  generation  of  reports  using  the  Adaption  Report  Generation 
subsystem,  the  event  that  caused  the  breakpoint  to  be  achieved  should  be 
listed  on  the  output.  This  could  be  the  current  adaption  step  or  a  message 
indicating  that  adaption  had  completed. 
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Appendix  B 

DNPS  Overview  And  MBR_AAS  Evaluation 

B.1  SYSTEM  OVERVIEW  OF  DNPS 

The  DNPS  is  used  by  the  Defense  Communications  Agency  (DCA)  to  plan  for  the 
allocation  of  resources  of  the  Defense  Satellite  Communications  System  (DSCS)  in 
support  of  communication  requirements.  The  purpose  of  this  package  is  to  evaluate 
performance  of  various  resource  allocation  strategies  of  the  DSCS  network.  Such 
strategies  are  defined  by  user  scenarios  that  model  DSCS  communication  links,  networks, 
satellites,  earth  terminals,  and  jammers.  DNPS  is  the  resource  allocation/performance 
function  of  the  two  main  functions  that  comprise  the  DOSS.  The  DSCS  Automatic 
Spectrum  Analyzer  (DASA)  is  the  companion  DOSS  function  that  allows  monitoring  of  a 
DNPS-analyzed  network.  Typical  DASA  monitoring  functions  measure  and/or  compute 
power,  received  signal-to-thermal  noise  ratio  (C/kT),  and  power  versus  frequency 
spectrum  data  for  the  entire  transponder  bandwidth  or  selected  channels  or  links  within  a 
transponder.  Such  information  is  used  for  comparison  against  the  results  predicted  by 
the  DNPS  model.  DOSS/DASA  controls  reports  and/or  a. arms  that  indicate  equipment 
degradation  or  changes  to  network  utilization.  Together,  DNPS  and  DASA  functions 
enable  a  user  to  configure  and  monitor  DSCS  network  configurations. 

B.2  FUNCTIONAL  DESCRIPTION  OF  THE  DNPS 

The  DNPS  implements  several  functions  that  support  definition,  analysis,  and 
performance  reporting  of  the  satellite  communication  networks  based  on  allocation  of 
communication  subsystem  resources.  Figure  B-l  depicts  the  functional  organization  of 
DNPS.  A  summary  of  the  functions  follows: 

•  DNPS  Supervision 

The  DNPS  supervisor  provides  operator  control  over  all  DNPS  functions  via 
menus  and  prompts  to  the  operator.  In  addition,  it  provides  communications 
with  DASA,  24-hour  activity  logging  of  users,  and  maintenance  of  system 
state  for  function  initialization. 

*  Procedure  Definitions 

Procedure  definition  allows  the  operator  to  store  a  sequence  of  keystrokes 
that  may  be  later  retrieved  and  executed  in  place  of  operator  command  input. 

If  a  procedure  file  has  an  illegal  keystroke  sequence,  the  file  processing  is 


Figure  B-1.  Functional  Organization  of  ONPS 
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terminated  automatically.  Command  input  is  resumed  from  the  user's  console. 


•  Static  Data  Base  Loading 

Automatic  loading  of  the  static  data  base  is  performed  by  this  function.  It 
loads  all  files  into  memory  that  are  necessary  to  support  DNPS  functions.  If  a 
privileged  user  (operational  account)  changes  these  data,  then  the  static  data 
base  loader  ensures  that  all  inputs  are  within  bounds. 

•  Scenario  Definition 

Ten  scenario  definitions  are  accessible  through  a  user's  library  or  a  copy 
function  from  another  user's  account.  The  scenario  definition  function  allows 
a  user  to  select  from  the  above  and/or  build  a  new  scenario  based  on  the 
active  scenario.  This  is  accomplished  by  selections,  additions,  deletions,  or 
modifications  to  the  dynamic  data  base  (the  active  scenario).  Such  changes 
to  the  active  scenario  are  checked  for  legitimate  entry,  and  errors  are 
reported.  Access  to  a  stored  data  base  is  checked  against  the  static  data 
base  for  compatibility.  The  operator  is  warned  of  all  incompatible  elements. 

•  Analysis  Support 

The  analysis  support  function  is  activated  for  an  operator-defined  scenario  in 
order  to  generate  needed  information  for  the  resource  allocation  and 
performance  analysis  or  report  functions.  Several  calculations  are  performed 
based  on  the  active  scenario: 

o  Ephemeris  generation  from  the  orbit  vector, 
o  Terminal/jammer  range,  range/rate. 

o  Terminal/jammer  azimuth/elevation  locations  (with  satellite-in-view  or 
out-of-view  information). 

o  Calculations  for  normal  atmospheric,  free  space,  and  total  path  loss. 

o  A  terminal/jammer  MBA  pattern  index  generator  used  for  accessing 
singlet  data  on  a  sorted  highest  to  lowest  beam  contribution  amplitude. 
This  is  done  for  each  terminal  and  jammer  for  each  MBA. 

o  Calculation  of  the  gimbal  dish  antenna  (GDA)  directive  gain  based  on 
pointing  information. 


o  Earth  coverage  directive  gain  for  all  antennas. 

*  Satellite  Loading 

The  satellite  loading  function  provides  automatic  allocation  of  channel 
assignment,  coding  type,  and  modulation  type  for  operator-specified  FDMA 
links.  Criteria  for  this  function  are  based  on  available  satellite 
power/bandwidth  and  constraints  imposed  on  link,  link  modulation/coding,  and 
antenna/channel  connectivity  defined  by  the  active  scenario. 
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*  Network  Resource  Allocation 

The  network  resource  allocation  function  selects  all  network  parameters 
required  to  compute  network  performance  analyses.  The  operator  can  select 
parameters  manually  or  call  algorithms  which  generate  them  automatically. 
The  following  parameters  are  assigned  or  utilized: 

o  Uplink  transmitter  power  and  effective  isotropic  radiated  power  (EIRP)  for 
each  network  link 

o  Transponder  channel  gain  settings 
o  GOA  pointing  coordinates  and  directive  gains 
o  Satellite  transponder/channel  connectivity 
o  Quantized  beamweights  and  directional  gains  for  all  MBAs 

*  Network  Performance  Analysis 

The  network  performance  analysis  function  estimates  network  performance 
using  analytic  and  tabular  models  for  terminal,  uplink,  satellite,  and  downlink 
parameters  and  effects.  Input  consists  of  operator-selected  options  and 
network  parameters  determined  by  the  resource  allocation  function.  Outputs 
can  be  compared  to  measurable  network  parameters  such  as  link  margins, 
terminal  power  margins,  received  signal  strength,  C/kT  transponder  output 
backoff,  etc.  The  operator  uses  the  network  performance  analysis  function  to 
obtain  and  display  the  network  performance. 

*  Report  Generation 

The  report  generation  function  is  responsible  for  formatting  and  outputting 
reports  to  various  soft  and  hardcopy  devices.  It  is  capable  of  accessing  the 
static  data  base  and  active  scenario  data.  The  following  accounting 
information  is  in  each  header: 

o  Date/time 

o  Security  Classification 
o  Operator  Identification 
o  Scenario  Identification 
o  Title 

o  System  State 
o  Page  Number  (e  g.,  1  of  5) 

Reports  cover  all  facets  of  DNPS  functions.  They  are  embodied  in  many 
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report  types.  Report  topics  aggregate  user-defined  parameters,  models,  and 
configurations  that  comprise  all  DOSS  capabilities.  Topics  are: 

o  Network  Performance  and  Configuration  Summaries 
o  Link  Performance,  Analysis,  and  Allocation 
o  Terminal  and  Jammer  Characteristics 
o  Satellite  Analysis  and  Parameters 
o  Antenna  Characteristics  including  Contour  Plots 
o  ECCM  Network,  Link,  Terminal,  and  Parameter  Summaries 
o  DASA  Alarms  and  Reports 

•  ECCM  Adaptation 

The  ECCM  function  sorts  and  assigns  traffic  loads  to  allocate  as  many  circuits 
as  possible  in  a  stressed  environment.  Reduced  traffic  loading  in  a  stressed 
environment  must  satisfy  network  performance  margins,  constraining 
parameters  and  traffic  ranking  definable  for  the  DNPS  III  environment. 
Constraints  ignore  all  links  and  terminals  which  are  out-of-view  or  turned  off. 
Power-constrained  links  are  not  altered. 

•  DASA 

The  DASA  function  provides  an  interface  between  DNPS  and  the  DASA  system. 

It  checks  operator  input  for  validity  and  transmits  configuration  and  control 
commands  to  DASA.  This  function  receives  and  formats  reports  and  alarms 
from  DASA. 

•  Satellite  Tasking  and  Configuration 

The  satellite  tasking  and  configuration  function  provides  the  Man-Machine 
Interface  (MMI)  necessary  for  operator  control  of  data  transfer  to  and  from  the 
Satellite  Configuration  Control  Element  (SCCE).  The  SCCE  is  responsible  for 
satellite  monitoring  telemetry,  and  configuration  control  of  the  satellite 
communication  subsystem. 

B.2.1  Operational  Accounts 

Operational  accounts  contain  the  operational  scenario  of  the  actual  network 
configuration.  As  such,  they  are  typically  assigned  to  the  Satcom  Network  Controller 
(SNC),  who  can  exercise  a  broad  range  of  capabilities.  An  operational  account  has  five 
basic  capabilities.  The  first  three  three  items  are  contingent  on  OCA  Operations  Center 
(DCAOC)  approval. 


*  Modify  the  DNPS  online  static  data  base.  This  includes  static  terminal,  static 
jammer,  modem,  filter,  multiplexer  and  satellite  ephemeris  data. 

*  Modify  the  operational  scenario.  This  includes  modification  of  communication 
link,  satellite  configuration,  and  earth  terminal  parameters. 

*  Create  new  DNPS  data  bases  (new  operational  data)  that  can  be  passed  to  the 
DASA  system  for  use  in  monitoring  the  downlink  signal. 

*  DASA  commands  and  acknowledgement  of  DASA  alarms. 

*  Use  of  all  privileges  available  to  analyst  accounts. 

B.2.2  Analyst  Accounts 

Analyst  accounts  allow  the  user  to  plan  scenarios  that  do  not  modify  the  operational 
scenario.  Each  analyst  account  user  may  interact  with  the  DNPS  software  by  creating  or 
modifying  scenarios  from  his/her  library  of  scenarios.  Scenario  interaction  is  performed 
on  the  active  scenario.  Saved  scenarios  defined  in  analyst  accounts  may  be  copied  into 
other  analyst  accounts. 

B.3  SYSTEM  ARCHITECTURE 

The  DNPS  system  architecture  may  be  examined  with  respect  to  the  software  and 
hardware  configurations  as  discussed  below. 

B.3.1  Software  Configuration  of  DNPS 

DNPS  is  configured  as  a  single  shared  image  with  multiuser  access.  As  a  single  task 
it  supports  multiple  users  by  multiprocessing.  Access  to  DNPS  is  granted  by  limiting 
execution  to  users  with  valid  operational  or  analyst  accounts  defined  on  a  site  basis.  A 
login  procedure  file  checks  the  validity  of  the  user's  account  prior  to  program  execution. 
DNPS  is  menu  driven,  with  submenu  selections  displayed  upon  entry  to  the  function. 
User  consoles  are  formatted  with  the  current  function  and  a  prompt  for  selectable  menu 
items  or  parameter  input  for  a  specific  function.  Regression  from  submenus  is 
accomplished  by  definition  of  the  "level-up"  function  key.  This  key  cancels  the  current 
function  level  and  returns  to  the  next  highest  level  of  menus.  In  this  way  the  operator 
can  control  the  sequence  of  all  program  execution. 


B.3.2  Hardware  Configuration  of  ONPS  (OCEC  and  Field  Sites) 

Hardware  configuration  of  OCEC  and  field  site  systems  varies.  Field  sites  have  been 
or  are  being  configured  with  Digital  Equipment  Corporation  VAX  11/730  front  ends  to 
replace  the  PDP-11/04  as  shown  below  in  Figure  B-2.  The  DCEC  configuration  supports 
an  additional  man-machine  interface  that  is  not  on  the  field  equipment.  This  description 
applies  to  the  DCEC  configuration  with  field  sits  exceptions  noted.  The  major  component 
of  DNPS  is  a  VAX- 11/780  connected  to  one  of  six  user  stations.  Two  remote  access 
stations  consist  of  a  POP- 11/04  connected  to  the  VAX  via  DECnet.  The  POP- 11 /04s 
support  their  Tektronix  4014  graphics  terminal,  Versatec  1200A  printer/plotter  and  the 
Televideo  920  C  console.  (Twin  structures  are  noted  as  <1  of  2>).  The  local  access 
configuration  (DCEC  only)  supports  a  Tektronix  4014  console,  a  Versatec  1200A 
printer/plotter,  and  five  VT  100  user  consoles.  DCMTEST  (a  software  module)  emulates 
the  PDP-11/04  function  for  the  local  access  station  and  performs  input  data  conversion 
from  the  VT100  terminal. 

B.3.3  Man-Machine  Interface 

The  man-machine  interface  ( MMI )  is  the  basic  e  xponent  that  provides  user 
input/output  access.  There  are  four  peripherals  that  give  the  user  physical  access  to 
DNPS.  They  allow  the  user  to  select  from  a  menu  (or  submenu),  enter  parameter  values, 
display  parameters/reports,  and  make  hardcopies  of  parameters/reports.  They  are: 

•  VT100  Terminal  Primary  menu  input  device  for  local  commanding  to  DNPS 
software  at  DCEC.  TVI  920  A  Terminal  Primary  menu  input  device  for  remote 
commanding  of  DNPS.  Tektronix  4014  Primary  report  device  for  displaying 
system  parameters  or  report  generation  output.  Secondary  features  include 
the  X-V  cursor  control  knobs  which  are  used  in  defining  area/gain  coutour 
definitions  for  the  MBR_AAS.  (This  device  is  not  supported  for  input  at  remote 
sites.) 

•  Versatec  Printer/Plotter  Primary  hardcopy  device  that  directly  copies  the 
Tektronix  CRT  information  by  manual  command. 

•  Tektronix  4631  Hardcopy  Device  Copies  graphic  display  output  from  the 
Tektronix  4014  Display 


Figure  B-2.  System  Overview  of  Hardware  Configuration  (DNPS) 
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B.4  PROBLEMS  AND  RECOMMENDATIONS 

While  the  DNPS  system  has  extensive  capabilities,  a  major  issue  is  centered  on  its 
single-task  nonoverlaid  environment.  The  execution  module  includes  roughly  450 
subprograms.  These  subprograms  support  17  functions,  which  manipulate  or  display 
common  data  areas.  Recommendations  for  DNPS  system  configuration  are  described 
below: 

*  Use  of  Overlays 

Overlay  loading  is  a  VAX/VMS  linkage  option  that  allows  subprograms  to  share 
a  common  memory  space.  This  technique  reduces  memory  requirements  on 
the  VAX  computer  as  well  as  VAX  system  requirements  for  each  user. 

*  Use  of  Multitasking 

Multitasking  may  be  used  to  separate  functional  elements  of  DNPS  into 
independent  tasks.  As  multitasks,  each  function  is  compiled,  linked,  and 
executed  as  a  separate  task.  Users  in  the  program  development  cycle  would 
not  be  required  to  embody  the  entire  DNPS  in  their  work  effort.  DNPS  would 
be  relieved  of  evolutionary  strain  in  that  new  or  modified  tasks  would  not 
compete  for  space  requirements  imposed  by  a  large  single  task. 

B.S  RESULTS  OF  THE  MBRAAS  EVALUATION 

The  MBR  AAS  is  a  working  version  of  the  DCEC  software  that  implements  the 
algorithm  described  in  the  subtask  C  statement  of  work.  The  modules  TESTTEK,  TEKSORT, 
and  RETMBR,  which  make  up  the  MBR_AAS,  operate  as  three  stand-alone  packages. 
Integration  of  MBR  AAS  requires  an  understanding  of  the  methods  used  by  the  MBR_AAS 
and  DNPS  to  generate  or  utilize  MBR  beam  weights.  This  report  describes  methods  for 
steering  criterion  of  the  M8R,  summarizes  DNPS  methods  of  beam  weight  selection,  and 
details  the  data  and  algorithms  used  by  the  MBR_AAS.  Case  studies  of  the  MBR  AAS  are 
summarized  with  conclusions  on  MBR  AAS  performance. 


B.6  SUMMARY  OF  METHODS  USED  FOR  MBR  STEERING  ALGORITHMS 


Methods  used  to  produce  MBR  beam  weights  depend  on  the  function  used  to 
generate  them.  The  DNPS  employs  three  different  methods  that  generate  separate  MBR 
beam  weights.  They  are  summarized  by  the  following: 

*  Network  Resource  Allocation 

Network  resource  allocation  defines  a  set  of  beam  weights  based  on  terminal 
loading. 

*  ECCM  Adaptation 

ECCM  adaptation  generates  beam  weights  using  the  same  algorithm  as 
Resource  Allocation.  The  algorithm  is  iterative  and  based  on  a  stressed 
environment. 

*  Scenario  Definition 

Scenario  definition  allows  the  operator  to  manually  input  beam  weights. 

Each  method  of  input  generates  a  set  of  beam  weights.  While  the  resource  allocation 
and  ECCM  adaptation  beam  weights  are  interdependent  the  final  selection  of  active 
scenario  beam  weights  may  be  chosen  by  the  operator.  Report  results  are  generated  by 
computing  the  directive  gain  for  the  entire  azimuth/elevation  fie  d  of  view  based  on  active 
scenario  beam  weights.  (Directive  gain  is  defined  later  in  this  appendix.)  Plotting 
routines  map  the  directive  gain  levels  into  azimuth/elevation  coordinates.  A  template  of 
the  earth  with  continental  boundaries  can  be  overlaid  on  this  gain  contour.  The  gain 
contour  process  is  then  complete. 

The  MBR_AAS  algorithm  was  developed  to  automate  the  contouring  of  directive  gains 
by  defining  global  areas  that  have  high  or  low  sensitivity  (gain).  Such  areas  can 
represent  locations  for  friendly  or  hostile  earth  terminals.  The  MBR  AAS  will  take  the 
defined  areas  as  input  and  generate  a  set  of  complex  beam  weights  that  attempt  to 
satisfy  the  area/gain  definition.  The  MBR  AAS  methodology  consists  of  three  stand-alone 
packages.  TESTTEK  defines  area/gain  constraints.  TEKSORT  sorts  these  constraints  on  an 
area  basis.  RETMBR  computes  beam  weights  that  attempt  to  satisfy  these  constraints. 
Graphics  software  is  included  that  allows  various  report  generation  capabilities.  The 
following  sections  highlight  the  important  features  of  the  three  packages. 


TESTTEK  provides  a  means  to  define  unique  areas  overlaid  on  a  global  map  with 
continental  boundaries.  Several  areas  may  be  encompassed  with  nonintersecting 
polygons.  TESTTEK  has  two  major  functions:  providing  the  man-machine  interface  (MMI) 
and  generating  an  output  file  that  stores  the  selections  made  in  this  section.  Input 
consists  of  map  area/gain  definitions.  Primary  inputs  are  user-defined  polygons  around 
areas  of  interest.  They  are  made  by  X/Y  knob  positioning  of  cross  hair  cursors  of  the 
Tektronix  4014.  Such  areas  are  labelled  (three  characters)  and  assigned 
minimum/maximum  gain  constraints.  Up  to  30  areas  may  be  defined.2  When  the  data 
input  phase  is  complete,  a  file  is  written  to  reflect  the  operator's  area/gain  input  session. 

B.6.2  TEKSORT 

TEKSORT  is  an  execution  module  called  directly  after  TESTTEK.  It  has  three  main 
subprograms  that  perform  area  priority  sorting.  Areas  of  interest  are  defined  by  the 
TESTTEK  output  file.  They  are  described  in  terms  of  azimuth/elevation  locations,  area 
labels,  and  gain  constraints.  These  data  are  sorted  on  an  area  size  basis  so  the  steering 
algorithms  give  an  equal  priority  to  all  areas  under  con  ^  deration  proportional  to  their 
size.  An  output  file  is  generated  that  contains  the  sorted  results.  Section  B.7.6  details 
this  method. 

B.6.3  RETMBR 

RETMBR  is  the  program  that  embodies  the  beam  forming  process.  This  package  takes 
the  sorted  file  from  TEKSORT  and  applies  the  beam  forming  algorithms  to  match  the  area 
definitions  defined  in  TESTTEK.  RETMBR  also  contains  various  display/report  features  that 
summarize  intermediate  results  and  writes  a  beam  weight  file  for  final  results.  The 
program  has  two  basic  outcomes;  it  will  converge  to  the  constraint  requirements  or 
report  an  impasse  condition  if  the  area/gain  definition  has  not  been  realized.  The  goal  of 
this  program  is  to  automate  the  beam  weight  selection  process  so  that  the  operator  skills 
necessary  to  produce  the  required  operational  gain  contours  are  reduced. 


2The  number  of  areas  is  a  compile  time  constant. 


8.7  SUMMARY  OF  METHODS  DATA  AND  ALGORITHMS  USED  BY  RETMBR 

The  following  sections  are  related  to  the  RETMBR  and  are  discussed  in  order  to 
provide  an  understanding  of  the  linear  algebra  and  numerical  analysis  associated  with 
MBR  steering  algorithms  used  in  RETMBR. 


B.7.1  Linear  Algebra  Used  in  MBR  Algorithms 

This  section  details  a  basic  steering  model,  the  linear  algebra  and  the  assumptions 
used  in  the  directive  gain  and  steering  algorithms  found  in  RETMBR.  The  RETMBR  module 
is  used  to  develop  and  display  beam  weights.  Area/gain  parameters  are  defined  in  the 
input  phase  of  TESTTEK.  The  area  of  interest  corresponds  to  the  singlet  data  matrix  (A), 
and  corresponding  gain  limits  for  these  areas  are  defined  in  the  Boundhi/low  vectors. 
These  input  parameters  are  used  to  produce  optimization  variables  of  the  RETMBR 
package.  Five  basic  variables  are  defined  and  used  in  the  computational  modules  of 
RETMBR.  The  majority  of  these  variables  reside  in  RETMBR  subprograms  prefixed  with 
"OPT"  {OPTOOO  through  OPT351}.  They  are: 

•  X  -  The  normalized  beam  weight  vector 

•  \  -  The  directive  gain  vector 

•  PO  -  The  partial  derivative  of  directive  gain  with  respect  to  beam  weights 

•  Tconst  -  The  constraint  equation 

•  BC  -  The  beam  quality  equation 

Two  variables  are  defined  for  complex  numbers  within  RETMBR.  They  represent  identical 
operations  for  the  real  and  imaginary  parts  of  the  variable.  The  following  sections  use 
complex  notation,  so  these  definitions  are  used  to  simplify  complex  operations. 

B.7.2  Cost  Function  and  Steepest  Descent  Algorithms  for  a  Multiple  Beam  Antenna 

All  MBR  antenna  beam  steering  algorithms  must  have  a  performance  criterion  or  cost 
function  for  optimization  of  beam  weights.  This  section  reviews  some  basic  techniques 
of  adaptive  beam  forming.  A  classical  cost  function  is  the  minimization  of  the  mean 
squared  error  between  the  actual  gain  contour  and  the  desired  gain  contour.  This  penalty 
is  used  to  avoid  large  deviations  between  the  desired  and  actual  beam  weights.  The  cost 
function  has  the  form: 


=  I  area  H‘iBl,rmin,l  =>  0 


B.1 


where: 


CF  Cost  function;  the  parameter  to  minimize 

terminal  An  individual  terminal 

area  All  the  area  locations 

9aintermmai  Computed  receive  antenna  gain 
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gaindesjred  Desired  receive  antenna  gain 

for  earth  location  terminal 
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The  steepest  descent  steering  algorithm  employs  the  gradient  operator  to  update 
beam  weight  selection.  This  algorithm  updates  beam  weights  by  selecting  them  in  the 
negative  gradient  of  the  cost  function.  This  is  represented  by: 

W(k+1)  =  W(k)  -  u7(CF)  B.2 

where: 

W(k)  Current  beam  weights  (k,h  iteration) 

W(k+1)  Next  set  of  beam  weights  ([k+1],r  .teration) 
y  A  bounded  constant  selected 

to  make  the  algorithm  converge 
V  The  gradient  operator: 

7(CF)  -  3(CF)/3Re(X)  ♦  3(CF)/3lm(X) 

where: 

X  The  complex  beam  weight  space:  W  ■  Re(X)  +jlm(X) 

CF  The  cost  function 

Re(),lm()  The  real  and  imaginary  parts  of  the  vector 

Two  factors  that  affect  the  steepest  descent  (negative  gradient)  method  are  the 
selection  of  convergence  constant  (u)  and  quantization  of  the  beam  weights  imposed  by 
OCSC  III  satellite  electronics.  The  convergence  constant  is  a  scaling  factor.  It  scales  how 
much  of  the  gradient  should  be  used  to  adjust  the  beam  weights.  By  choosing  the  scale 
factor  too  large,  the  algorithm  will  diverge  or  oscillate.  However,  a  small  scale  factor 
makes  the  algorithm  converge  too  slowly.  A  second  factor  affecting  performance  is  the 
satellite  implementation  of  power  and  phase  states.  The  DSCS  III  MBR  antenna  feed 


electronics  produce  discrete  phase  shifts  and  power  levels.  The  gradient  algorithm  must 
be  consistent  with  the  limited  number  of  discrete  values  possible  in  the  actual  equipment. 

To  cope  with  these  design  problems.  OCEC  Code  R420  developed  an  algorithm  to 
account  for  these  design  problems.  This  algorithm  accounts  for  discrete  step  size 
limitations  in  the  power/phase  electronics  that  are  inherent  in  the  satellite.  The  model 
further  employs  an  area-selection  algorithm  that  gives  equal  priority  to  all  areas  of 
interest.  Methods  used  in  this  algorithm  are  described  in  the  following  sections. 

B.7.3  Singlet  Data 

Singlet  data  is  the  electromagnetic  field  strength  that  each  singlet  beam  can  realize  at 
a  given  azimuth/elevation  coordinate  (0.2°  granularity).  Although  these  singlet  beams 
should  ideally  be  circularly  symmetric  with  J^xJ/x  gain,  a  review  of  individual  singlet 
beam  contours  reveals  significant  asymmetries.  Figure  B-1  shows  a  typical  singlet  beam 
pattern  for  ±9°  azimuth/elevation  angles  that  encompass  earth  coverage.  The  non- 
symmetric  gain  sidelobes  are  a  result  of  lens  aberrations  and  other  factors. 

Figure  B-3.  Typical  Singlet  Beam  Pattern  for  MBR 


The  selected  singlet  data  matrix  (A)  is  defined  as  the  subset  of  singlet  data  for  the  areas 
of  interest.  These  areas  are  operator-defined  in  the  TESTTEK  package.  The  array  A  has 
the  form: 

Selective  Singlet  Data  or  Beam  Contribution  Array  {M,61} 
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Each  singlet  element  is  a  complex  value  that  is  defined  in  terms  of  real  (a)  and 
imaginary  (0)  parts.  A  general  element  (a^  +  B^)  represents  the  jth  beam  contribution  at 
the  ith  azimuth/elevation  point  selected  from  the  field  of  view.  Each  row  represents  the 
beam  vector  for  a  given  point  and  each  column  represents  the  area  vector  for  each 
singlet  beam.  The  number  of  columns  is  fixed  at  61.  The  number  of  rows  or  areas  (M) 
may  vary  from  one  point  to  full  coverage  of  8281  points  (the  91  x  91  grid). 

B.7.3.1  Area  Bound  Constraints  or  Desired  Gain 

The  TESTTEK  program  defines  the  desired  gain  constraints  for  the  areas  of  interest. 
An  area  of  interest  contains  a  set  of  points  enclosed  by  a  user-drawn  polygon.  All  points 
within  the  polygon  have  the  same  desired  gain.  They  are  referred  to  as  the  area  bound 
constraints.  These  constraints  are  specified  in  terms  of  high  and  low  gain  limits: 


Area  Definition  Bound  Limits  {na  x  2} 

Boundhi(na)  -  User  defined  (dB)  B.4 

Boundlow(na)  =  User  defined  (dB)  B.5 


Where; 

na  is  the  number  of  user-defined  areas 
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B.7.3.2  Beam  Weight  Vector 

The  beam  weight  vector  (B)  contains  the  initial  beam  weights  that  may  vary  from  ±1 
continuously.  While  the  current  MBR_AAS  program  uses  a  set  of  zeroed  beam  weights  as 
the  initial  beam  weight  vector  there  is  no  restriction  on  the  beam  weights.  This  implies 
that  beam  weights  may  be  supplied  from  other  user  results  or  inputs.  The  vector  shown 
is  an  example  of  the  beam  weight  matrix  with  the  maximum  boundary  constraints: 


Beam  Weights  f61.11 
BW  ±  1.000;  i= 1 ,6 1 


B.7.3.3  Normalized  Beam  Weights 

Normalized  beam  weights  are  computed  so  their  root-mean-square  (RMS)  sum  is 
unity  and  quantized  to  realizable  antenna  settings  (61  gain  and  phase  states).  The 
equation  depicts  their  real  (y)  and  imaginary  (6)  parts.  The  normalized  beam  weight 
vector  fXj  has  the  form: 


Ith  Element  of  Normalized  Beam  Weights  {1,1} 


X;  =  Quantize<BW.  /  {X61|BWj|2}1 


Vector  of  Normalized  Beam  Weights  {61,1} 


Y,  +  i«, 
Yz  +  i$2 


*ei  +  i66i 


*1-." 
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B.7.3.4  Computed  Gain 


The  computed  gain  (or  sensitivity)  vector  (G)  is  computed  as  the  product  of  the 
singlet  data  matrix  times  the  normalized  beam  weights  vector: 

Computed  Gain  (M.1) 

G  >  A  X  8  9 


B.7.3.S  Directive  Gain 

The  resultant  gain  vector  G  is  modified  by  the  MBR_AAS  to  produce  the  contour  data 
(directive  gain  (X)).  Directive  gain  is  a  direct  function  of  the  computed  beam  weights. 
MBR_AAS  updates  the  beam  weight  vector  X  to  make  the  computed  gain  vector  lambda 
(X)  constrained  by  the  desired  gain  bounds  (Eq.  B.4  and  B.5).  This  equation  scales  directive 
gain  into  decibel  units.  Note  that  the  gain  G  is  defined  in  complex  space  whereas  the 
directive  gain  vector  (X)  is  magnitude  only. 

Directive  Gain  {M,1} 

X(  =  1 0*1  og ,  0(Sf*GG*)j  j  B.10 


where: 

Sf  Scale  Factor:  GE  Supplied 

G  Equation  B.9 

G*  The  complex  conjugate  transpose  of  Equation  B.9 

{ (  Form  a  vector  from  the  diagonal 

elements  of  the  matrix 

i  An  element  from  the  set  of  elements  i  ■  1  to  M 


Expanding  equations  B.9  and  B.10  into  their  composite  elements  is 
presented  for  clearity: 

Gi  a  Sk-1.6!  <a,.kYk>  -  Bik«k)  +  i(BikYk  ♦  aiksk) 

» 

a  =  Re(Gj)  ♦  ilmfG;) 

J  (OjOiXi  8  ("•(Gi))2  ♦  (Im(Gj)2) 

j  where: 

-  ReO  The  real  part  of  the  complex  vector 

lm()  The  imaginary  part  of  the  complex  vector 

^  j  The  imaginary  unit  vector 


B.lOa 

B.lOb 


B.IOc 
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B.7.3.6  First  Partial  Darivatlvas 

Once  the  initial  choice  of  the  beam  weight  vector  X  is  chosen,  the  first  partial 
derivative  of  lambda  (X)  is  evaluated  with  respect  to  the  magnitude  of  each  directive  gain 
element.  Two  sets  of  partial  derivatives  are  evaluated  for  lambda  with  respect  to  the  real 
(6)  and  imaginary  (y)  parts  of  the  beam  weight  vector  X  The  partial  derivatives  are  used 
by  the  steering  algorithm  to  determine  if  the  set  of  beam  weights  will  add  to,  subtract 
from,  or  leave  unchanged  the  directive  gain  vector  X  for  the  areas  under  consideration. 
The  first  partial  derivatives  are  computed  by  the  matrix  operation: 

Partial  Derivatives  {M,61} 

P0M,61  a  1  3xsi 

In  an  expanded  form  the  partial  deratives  are: 


Where: 
a,  8 
aT.0T 

Y 

6 

X 

Re().lm() 


P°-y  =  [M  I61  2(-8TRe(X)+oTlm(X)J 
P05  3  Im  Isi  2taTRe(X)+BTlm(X)] 


The  real  and  imaginary  elements  of  Equation  8  3 

The  transpose  of  a,  8 

The  real  part  of  the  partial  derative 

The  imaginary  part  of  the  partial  derivative 

Directive  gain  (Equation.  B.10) 

Functions  that  return  the  real  and 
imaginary  parts  of  the  argument 


B.7.4  Beam  Selection  Algorithm 

Two  measures  are  computed  to  determine  if  the  beam  weight  vector  selection  X  is 
valid:  the  constraint  equation  (Eq.  B.15)  and  the  beam  quality  index  (Eq.  B.16),  which  are 
both  discussed  below.  The  X  vector  is  chosen  in  a  straightforward  manner.  The  choice 
is  simply  the  best  fit  for  one  of  the  points  (1  through  M)  irrespective  of  all  other  points; 
therefore,  a  solution  is  localized  to  that  individual  point  from  an  area  of  interest. 

The  current  MBR_AAS  computes  beam  weight  updates  based  on  the  beam  quality 
equation  (Eq.  B.19).  The  magnitude  of  the  first  partial  derivatives  allows  the  beam  quality 
algorithm  to  determine  if  the  computed  beam  weight  vector  (X)  biases  the  overall 
contour.  The  magnitude  of  the  first  partial  derivative  is  a  complex  conjugate  product: 


VwV.v * "Lvv.  \-.v v .wSv 


|  3X/3X  |  »({Re{PD)  ♦  jlm(PO)l  (Re<PO)  -  jlm(PO)]),/2 


8.14 


where: 


|  ...  |  Denotes  a  vector  magnitude  operator 

Re(  ...  )  The  real  part  of  the  vector 

lm{  ...  )  The  imaginary  part  of  the  vector 

These  magnitudes  are  used  in  two  different  criteria  for  the  update,  as  is  discussed  in 
the  beam  quality  section. 

B.7.4.1  Constraint  Equation  {Scalar} 

The  constraint  equation  is  a  measure  of  how  well  the  computed  beam  weights 
compare  to  the  realizable  values  (i.e.,  how  well  the  updates  conform  to  Equation  B.8).  The 
constraint  equation  is  not  bounded  by  satellite-imposed  constraints  of  discrete  gain  and 
phase  states.  Constraint  beam  weights  are  the  algorithm  computed  beam  weights. 
Equation  B.8  accounts  for  satellite-imposed  constraints.  While  the  constraint  equation  is 
not  used  in  beam  weight  updates,  it  supplies  a  measure  between  the  computed  beam 
weights  and  the  realizable  values.  Equation  B.15  scales  beam  weights  to  ±1000  for 
integer  mathematics.  If  the  computed  beam  weights  ideaily  equal  the  normalized  beam 
weights  (Eq.  B.8),  then  the  sum  of  the  magnitude  squared  would  be  one  million.  This 
may  be  defined  as: 

Tconst  I  XC  ♦  AXC  I2  =>  IQ8  ;  Exact  Fit  of 

Eq.  B.S  B.15 

where: 

Z61 1  ...  |  2  The  sum  of  the  vector  magnitude  squared 

XC  The  computed  beam  weights  (BW  times  1000) 

AXC  The  computed  beam  weight  updates  (BW  times  1000) 


B.7.4.2  Beam  Quality  Equation 

Beam  quality  is  the  controlling  variable  in  the  beam  weight  update  matrix.  Two 
modes  of  control  are  used  for  variable3  and  constant  update  step  size.  A  definition  of 
beam  quality  is  the  measure  of  how  well  a  particular  set  of  beam  weights  biases  the 
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overall  directive  gain  with  respect  to  the  desired  results.  Biasing  in  the  MBRAAS 
software  is  defined  as  changing  the  directive  gain  in  a  perverse  direction  by  the  overall 
contour  being  increased  or  decreased  more  than  some  desired  amount.  This  amount  is 
compared  to  epsilon  (e).  Epsilon  is  a  qualitative  measure  that  sets  an  upper  limit  on  the 
sum  of  perverse  beam  quality  elements  or  ’’moves.*  If  the  sum  of  the  beam  quality 
elements  (moves:  ♦ 1 ,  -1.  or  0)  is  smaller  than  epsilon,  the  beam  weight  is  accepted.  If 
the  sum  is  greater  than  epsilon,  the  beam  weights  are  rejected  and  the  MBR_AAS  selects 
a  new  area  of  interest  or  enters  an  impasse  upon  beam  weight  rejection.  Such  biasing 
would  tend  to  move  the  contour  toward  an  unwanted  result;  hence,  it  is  a  rejection 
criterion.  Biasing  is  compared  to  epsilon  by: 

Beam  Quality  Vector  (M,61) 

BCm  -  Im  OZ{\m  -  Bnd)  B.1B 

where: 

DZ{...}  Dead  Zone  sign  of  function:  ±1,  or  0 

M  The  area  of  interest 

Bnd  Area  definition  bound  limits  (hi  &  low) 

Bnd  -  Boundlow  when  low  bound  not  satisfied  (Equation  B.5) 

Bnd  ■  Boundhi  when  low  bound  satisfied  (Equation  B.4) 

«*Cm  <L  e  -  Accept  beam  weights 
BCm  >  e  -  Reject  beam  weights 


Beam  qualities  are  then  sorted  according  to  magnitude.  The  largest  magnitude  beam 
quality  is  used  as  the  next  area  of  interest.  Updates  to  the  beam  weight  vector  are 
formed  by  the  beam  quality  for  the  point  of  interest.  The  first  mode  of  steering  allows 
incremental  beamweight  updates  and  the  second  mode  integrates  the  unity  step  size 
update.  Equation  B.18  was  implemented  to  allow  a  proportional  amount  of  beam  quality 
to  update  the  beam  weights.  The  unity  step  size  update  (Equation  B.17)  was  removed 
from  MBR  AAS  because  none  of  the  test  cases  converged  with  this  choice.  The  following 
equations  depict  the  two  modes: 


a.  is 


xck+1  -  XCk  ♦  zupd.t„  BCk 


where: 

XC  Computed  beem  weights  et  iteration  step  k 

BC  Computed  beem  quality  et  iteration  step  k 
^upd«t««  Sum  over  ail  iteration  steps  (1  through  k) 

The  dead  zone  sign  function  is  shown  in  Figure  B-4.  It  returns  a  value  of  zero  or  ±1. 
in  the  constant  update  beam  quality  criterion,  the  update  is  simply  this  value.  In  the 
variable  update  criterion,  this  value  is  integrated  into  (added  to)  the  current  update  index. 


Figure  B-4.  Dead  Zone  Sign  Function 
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B.7.S  The  Iteration  Cycle  of  MBR_AAS 

Equation  B.18  represents  beam  weight  updates  as  a  function  of  beam  quality.  This 
equation  needs  to  be  normalized  and  quantized  to  implement  the  satellite-imposed 
constraints.  The  iteration  loop  is  completed  when  Equation  B.1S  is  normalized  according 
to  Eq.  B.7  and  B.8.  The  iteration  continues  until  ail  the  points  within  the  areas  of  interest 
are  constrained  by  their  desired  gains  or  the  operator  aborts  the  process. 
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8.7.6  Area  Salaction  Algorithm 


The  area  selection  algorithm  gives  equal  priority  to  all  areas  according  to  their  size. 
This  algorithm  sorts  areas  (points  of  interest)  in  a  unusual  fashion.  Points  are  defined 
within  the  areas  of  interest.  They  represent  the  singlet  data  encompassed  by  these  areas. 
These  points  are  labelled  from  1  through  M.  The  key  to  the  algorithm  is  how  they  are 
selected.  This  is  done  by  TEKSORT.  TEKSORT  sorts  the  points  (M)  by  selecting  them 
from  the  centroid  of  each  area.  It  alternates  the  areas  to  choose  from  by  their  size.  If. 
for  instance,  two  areas  are  under  consideration  and  each  area  contains  the  same  number 
of  points,  it  will  alternate  points  from  the  centroid  of  each  area.  Each  new  selection  will 
be  the  next  closest  point  to  the  centroid  of  each  area  until  all  the  points  are  evaluated,  if 
the  areas  of  interest  are  unequal  in  size,  a  proportional  number  of  points  will  be 
evaluated  according  to  size.  An  area  twice  a  large  as  another  area  will  have  points 
evaluated  twice  as  often  as  the  smaller  area.  The  proportionality  rule  holds  true  for  all 
defined  areas.  This  selection  process  queues  the  areas  into  the  beam  quality  steering 
algorithm.  When  the  current  set  of  areas  has  been  constrained  to  their  desired  gains, 
more  areas  are  introduced  from  the  area  priority  algorithm. 

8.7.7  Case  Studies  of  MBRAAS 

All  case  studies  were  derived  by  simple  combinations  of  singlet  beams.  The  beam 
weights  were  generated  and  verified  by  the  DNPS  scenario  definition  and  contour  map 
reporting  functions.  MBR  feed  elements  used  to  generate  the  case  studies  are  identified 
directly  below  the  figure  titles.  This  technique  was  used  to  generate  realizable  area/gain 
definitions  for  MBR_AAS  input.  Four  case  studies  are  presented  which  represent  a 
combination  of  area/gain  definitions  inside  and  outside  a  ±4°  look  angle  (or  pointing 
angle).  This  angle  is  referenced  from  the  satellite  to  the  Earth  location  in  terms  of 
azimuth/elevation  coordinates.  The  ±4°  look  angle  was  chosen  to  demonstrate  MBR_AAS 
convergence  properties.  Figures  B-5  through  8-8  depict  the  area/gain  definitions.  A 
three-character  alphanumeric  descriptor  is  the  label  for  area  of  interest  (labelled  ’area’). 
The  directive  gain  boundaries  for  the  area  of  interest  are  labelled  "above”  for  the  high 
limit  and  "below"  for  the  low  limit.  The  cases  with  figure  numbers  are  summarized  as 
follows: 
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Figure 

Gein  (dB) 

Gain  (dB)  Area  Description 

Number 

Above 

Below 

Case  1 

B-5 

23 

27 

"CIA*  terminal  inside  ±4°  look  angle 

17 

13 

"CIO*  terminal  cut  by  ±4°  look  angle 

Case  II 

8-6 

27 

23 

*C2A*  terminal  cut  by  ±4®  look  angle 

12 

8 

"C2B*  terminal  inside  ±4°  look  angle 

27 

23 

"C2C"  terminal  outside  ±4°  look  angle 

17 

13 

"C2D"  terminal  outside  ±4°  look  angle 

Case  III 

B-7 

22 

18 

"C3A"  terminal  inside  ±4°  look  angle 

7 

3 

"C3B'  jammer  inside  ±4*  look  angle 

Case  IV 

8-8 


27 


23 


"£4A"  terminal  outside  ±4°  look  angle 
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Casa  I  was  designed  to  test  the  correlation  of  singlet  beam  boresights  with  areas  of 
interest.  Area  'CIA"  is  centered  in  between  the  boresights  of  singlet  beams  40.  41,  and 
48.  Area  *C2A*  is  centered  under  the  boresight  of  singlet  beam  16.  Desired  gains  were 
chosen  so  the  four  beam  weights  are  equal  magnitude  with  zero  phase.  Over  half  of  the 
61  beams  contributed  dominant  magnitude  and  phase  components  to  the  solution.  This 
confirms  the  lack  of  algorithm  sensitivity  toward  singlet  beam  illumination  directly  under 
the  areas  of  interest. 

Case  II  was  designed  to  test  a  combination  of  converging  and  nonconverging 
area/gain  definitions,  and  the  area  priority  sorting  algorithm  (TEKSORT).  This  case  has 
areas  defined  inside,  outside,  and  cut  by  the  ±4°  look  angle  criterion.  The  algorithm 
failed  to  converge  after  1  hour  of  execution  time.  Not  one  point  from  area  "C2C"  was 
considered  in  this  time.  This  test  demonstrates  that  the  algorithm  cannot  combine 
converging  and  nonconverging  areas  of  interest. 

Case  III  was  designed  as  a  terminal/jammer  scenario.  The  terminal  and  jammer 
locations  were  widely  separated  to  avoid  any  tight  constraint  Both  areas  were  placed 
inside  the  ±4°  look  angle  to  avoid  convergence  problems.  Th.s  case  converged  after  2 
hours  and  20  minutes  of  computation  time. 

Case  IV  was  designed  to  test  areas  defined  under  a  large  look  angle.  Area  "C4A"  is 
defined  just  above  the  horizon.  After  1  hour  of  computation  time,  no  points  met  the 
constraints. 
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B.7.8  Conclusions  on  MBR_AAS  Performance 

The  test  cases  show  that  MBRAAS  performs  marginally  for  simple  area/gain 
definitions.  A  general  observation  from  Table  B.1  shows  that  high  gain  areas  develop 
outside  the  defined  areas.  Such  undesired  gain  demonstrates  lack  of  overall  power 
management  within  the  algorithm  In  summary,  four  distinct  problems  are: 

•  No  convergence  outside  a  ±4°  look  angle 

•  No  main  lobe  preference  for  areas  directly  under  a  singlet  beam 

•  Undesired  power  allocation 
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Tabla  b-1.  Summary  of  Beamweights  for  Cases  I  through  IV 
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*  No  full  convergence  for  any  definition  ever  achieved 

B.7.9  Status  of  MBR_AAS 

Two  Multiple  Beam  Receive  Resource  Allocator  Algorithm  packages  exist:  DCEC's 
original  model  (RETMBR)  and  the  LINKABIT  working  package  (MBRAAS).  The  original 
model  did  not  converge  for  any  of  the  four  test  cases:  hence,  no  observations  were 
presented.  The  LINKABIT  version  includes  two  changes.  Area  definition  arrays  have  been 
increased  from  300  to  4000  points.  (A  point  is  defined  as  one  element  of  ground 
coverage  defined  as  an  azimuth/elevation  coordinate.)  This  changed  the  possible  areas  of 
interest  from  roughly  6%  to  75%  of  Earth  coverage.  Allowable  step  sizes  for  the  beam 
weight  matrix  have  been  modified  to  change  from  a  constant  (0,±1)  to  an  integrated  step 
size  as  described  by  Eq.  B.18.  These  changes  enhance  the  program  capacity  and 
convergence  rate  but  do  not  warrant  serious  consideration  for  the  DNPS. 


Appendix  C 

OCT AILED  EXPLANATION  OF  CASE  STUDIES  FOR  MBR  AAS 


This  appendix  extends  the  results  of  Section  B.7  in  Appendix  B  and  provides  a  detailed 
explanation  of  the  performance  and  convergence  properties  of  the  MBR_AAS  software. 
The  Figures  B-3  through  8-6  and  Table  B-1  are  repeated  for  reader  convenience  as 
Figures  C-1  through  C-4  and  Table  C-1.  respectively.  Figures  C-5  through  C-13 
represent  intermediate  results  of  the  algorithms  from  Eq.  B.7  and  B.16.  MBR  AAS  creates 
these  reports  to  display  the  convergence  properties  of  the  DCEC-provided  algorithm  at 
each  iteration  update  as  explained  below. 

Figure  C-5  is  a  time  snapshot  of  four  Tektronix  4014  display  updates  as  the  MBR_AAS 
iterates  through  its  first  four  iteration  cycles.  The  leftmost  number  (4881)  represents  the 
current  point  under  analysis.  This  is  the  record  number  for  the  azimuth/elevation  number 
under  consideration  from  the  area  labelled  *C1A*  (see  Figure  C-1).  Record  4881 
represents  the  point  nearest  centroid  of  area  XI A*.  Immediately  following  the  area  label 
(CIA)  is  a  one-character  summary  field.  It  represents  a  summary  of  the  beam  quality 
equation  (Equation  B.16).  This  character  may  take  on  the  following  values: 

I  The  beam  quality  is  below  an  acceptable  value 

A  The  beam  quality  is  above  an  acceptable  value 

J  The  beam  quality  just  recently  became  an  acceptable  value 

B  The  beam  quality  just  recently  became  an  unacceptable  value 

Space  The  beam  quality  has  been  acceptable  for  several  updates 

The  next  set  of  122  symbols  consists  of  the  elements  of  the  dead  zone  sign  function 
(Equation  B.16)  with  1  through  61  imaginary  components  and  1  through  61  real 
components.  The  initial  row  is  all  zeros,  since  no  comparison  can  be  made.  Following 
rows  have  combinations  of  zero,  for  no  impact  on  beam  quality;  a  plus  sign  (+)  for 
increased  beam  quality,  a  minus  sign  (-),  for  decreased  beam  quality;  or  a  zero  (0)  for  no 
change,  or  a  space  (  ),  indicating  that  the  beam  quality  has  been  acceptable  for  several 
iterations.  The  rows  immediately  above  the  beam  quality  are  the  computed  beam  weights 
(Equation.  B.18)  The  122  numbers  represent  the  imaginary  and  real  components  (reading 
from  the  left  to  the  right).  For  example,  the  first  three  imaginary  beam  weights  for  the 
third  update  are  6,  3,  and  6.  Figure  C-6  through  C-13  detail  these  types  of  data  for  the 
case  studies.  Typical  figures  display  more  areas  of  interest  (up  to  58)  as  the  update 


Figure  C-3.  Case  III  Terminal/Jammer  Inside  Converging  Look  Angle 

Singlet  Beams  16,  22,  23,  &  32 
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Figure  C-4.  Case  IV  Terminal  Outside  Converging  look  angle 

Sinalat  B«am  34 


Summary  of  Beamweights  for  Cases  I  through  IV 
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Figure  C-7.  Cut  II  Updataa  48  and 


Figure  C-12.  Case  III  Update  380 
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Figure  C-13.  Case  IV  Non-convergence 


number  counts  the  number  of  iterations  into  the  algorithm. 

C.1  OBSERVATIONS  OF  CASE  I 

Case  I  is  represented  by  Figures  C-1,  C-5,  C-6  and  Table  C-1.  Figure  C-5 
demonstrates  the  integrating  dead  zone  sign  function  (Equation  B.18)  as  the  beam 
weights  (Equation.  8.8)  increase  with  the  sequence:  x(0)  *  0,  x(1)  *  1.  x(2)  *  3.  x(3)  *  6. 
Figure  C-6  details  full  convergence  as  all  the  areas  of  interest  shown  meet  the  constraint 
98  iterations  into  the  algorithm.  Observation  of  the  beam  weights  (Table  C-1)  shows  that 
over  half  of  the  beams  are  dominant.  The  area  definition  was  chosen  from  the  singlet 
beam  library4  to  center  area  "CIA"  between  singlet  beams  40,  41,  and  48  and  area  "C2A* 
directly  below  singlet  beam  16.  The  algorithm  makes  no  use  of  major  lobe  illumination. 
Table  C-1  shows  singlet  beam  16  as  one  of  the  lowest  in  magnitude. 

C.2  OBSERVATIONS  OF  CASE  II 

Case  II  is  represented  by  Figures  C-2,  C-7,  C-8,  and  Table  C-1.  This  case  is 
representative  of  typical  gain  coverage  contours.  A  noteworthy  observation  (shown  in 
Figures  C-7  and  C-8)  is  the  failure  of  the  algorithm  to  sati  fy  a  small  subset  of  area/gain 
points.  Twenty-one  points  were  considered  after  180  iterations  (approximately  1  hour  of 
execution  time).  While  beam  weights  were  produced,  the  MBRAAS  did  not  consider  any 
points  from  area  "C2C" 

C.3  OBSERVATIONS  OF  CASE  III 

Case  III  is  represented  by  Figures  C-9  through  C-12  and  Table  C-1.  This  case 
represents  a  terminal  near  the  satellite  substation  point  and  a  jammer  inside  the  ±4°  look 
angle.  Distances  between  terminal  and  jammer  areas  are  roughly  500  miles.  After  2 
hours  and  20  minutes,  the  terminal  area  (C3A)  was  properly  fit  but  the  jammer  location 
(C3B)  oscillated  in  and  out  of  the  bounds  (note  the  "J"  descriptor  on  all  jammer  points). 


4A  library  of  individual  singlet  baams  is  maintained  by  OCEC  Coda  R420 


C.4  OBSERVATIONS  Of  CASE  IV 

Case  IV  is  represented  by  Figura  C-13  and  Table  C-1.  This  case  represents  a  terminal 
location  near  the  horizon  (i.e.,  a  large  look  angle).  This  case  gives  ample  insight  to  the 
performance  of  this  algorithm.  Not  one  point  was  satisfied  after  one  hour  of  execution. 
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